Must a Scrum team stick with the Sprint commitment or is it just a forecast?

A sprint commitment is just that - a commitment to get a set amount of work done in a set amount of time; if your team can't achieve their goals, then they need to adjust the type and amount of work that they are committing to.

There is no "commitment" in Scrum. Read carefully Scrum Guide - there is only "forecast" mentioned everywhere. Even grep for "commitnment" and there is no results. It looks like a very small difference, but it has been main change in one of the Scrum Guide releases (AFAIR in 2011). Words which we are using builds our perception and reality. In last Scrum Guide version from August 2013 Sprint Goal is crucial for Scurm Team. Of course if team didn't met the Sprint Goal that means that there are probably some problems. "The effect of working  extra hours would motivate teams in doing more 'realistic' estimation of  stories and better knowing about the team velocity." No it won't. It will demotivate them. There are always high expectation from business. "Commitment" has been one of the tools which has been used by business and managers, who has been looking for opportunity to use "stick" ("sticks and carrots" method). Look at "The Team" as their are people not just another Scrum artifact. Motivation is something more complex than that. After few failures like that team-members will probably say that "Scrum sucks". This is one of the reasons why "commitment" has been removed from Scrum few years ago. There is assumption that people always do the best what they can, and work the best as they can. Working overtime leads to frustration and demotivates people, as Luke said. Sustainable pace and realistic goals is all what you need.

Forcing a team to complete all stories from the sprint backlog is highly counterproductive. Agile is about measuring the velocity of a team, not pushing a team to certain limits. Once you measure velocity, you can start learning, remove impediments, lift bottlenecks,... It's about establishing a relationship of trust and communication between the team and the product owner (and stakeholders). Forcing developers to work extra hours is exactly one of the reasons why waterfall isn't working :)

I disagree with the effects that you mention of working extra hours. Pressure by doing overtime doesn't motivate a team, nor does it help them to estimate better or get more insight into their velocity. What I've seen working are teams that failed to deliver, and then did a proper retrospective to understand what happened to learn from it. Even better would be that when a team recognizes that it can't meet the commitment during the sprint, it does a quick investigation to see if they can change their way of working during the sprint to solve it, and if so takes action. Work smarter, not longer! @BenLinders

Experiment. Do what works best for you.   We used to say that the sprint goal was a commitment. To meet the commitment the team would rush around at the end to get things done. Testing became a bottle neck and developers would sacrifice weekends and quality to get things done. The team would also showcase stuff that was still in development leading to false expectations of progress.  And they started under committing in sprint planning.   So in summary insisting the teams forecast was a commitment led to a lot of bad waterfall like behaviours and outcomes. It really turned each sprint into a short waterfall release. From what I've heard most people experience these problems when they use this approach.   Now we use Scrum and Kanban and say that velocity is just a forecast. We only showcase stuff that is really truly finished. If stuff is nearly finished at the end of a sprint we don't rush to complete it we just move it to the next sprint and finish it on day one or two.   Our aim is to make the workflow smooth and continuous because this allows people to work much more efficiently and effectively. We find it works much better. Try it and see.

No. As Luke points out the notion of a 'commitment' has changed in the Scrum Guides. This been one thing that the Scrum founders wished they had phrased differently using a term like 'forecast'. Many times the team fails to deliver what it forecast for reasons beyond their control such as sickness, interruptions etc. Requiring the teams to work overtime in such situations is a huge de-motivator. It will likely lead to things like 'agile sucks' because in traditional techniques they could likely make up the time later in the schedule. A team retrospective will help determine the reasons for delivering less than anticipated. And this should be done in a no-blame way by focusing on the facts and being open and respectful.

Technically, yes. Practically, not always. Why? You're working off estimates, which are just that — "estimates". If the team isn't improving their estimates over time, either: The team isn't working properly --> Management issue There are too many unknowns --> Work size issue (split stories) There are a bunch of studies showing that an equal amount of work can be completed in less time and it's the "focus time" that really counts. To increase your team's focus, I suggest hacking the Zeigarnik Effect and usinghttps://www.blossom.co/blog/how-to-focus-with-wip-limits.

My Scrum team originally did commitments (many years ago). It always annoyed me.  Somewhere along the way I asked in a retrospective where we had "pulled in" a small story or two, I commented how it was funny that when we came up short we had to put on a hair shirt and flog ourselves in the retro, but when we delivered more than planned, there was no ticker-tape parade.  I therefore called BS on "commitment", and the team basically agreed.  We stopped committing as of that Sprint.  I only found out later that the concept commitment had been dropped, or adjusted in meaning, by the Scrum community. The thing is, a properly-formed team is almost always implicitly committed.  Generally, good teams perform well because they like to perform well.  The chief motivator is being rock stars. Count yourself lucky if you can form such a team.

No.  In point of fact it is expected that a team will NOT predict perfectly.  Refining predictive capabilities is one of many iterative parts of the Scrum process. If you haven't read and aren't following this book, you aren't doing scrum.  It answers this and many other questions in a short and quite readable manner: http://www.amazon.com/Agile-Software-Development-Scrum-Series/dp/0130676349/ref=sr_1_3?ie=UTF8&qid=1393272133&sr=8-3&keywords=Scrum+for+Agile