14. Oktober 2013
The term Commitment was removed from The Scrum Guide (pdf) and replaced by the term Forecast back in 2011. Here is my rant against the concept of commitment as it is still used by many otherwise agile teams. If you don't do scrum, but any other development method that ties a fixed set of development tasks to an iteration, then this article is also for you. You must not mistake ceremonial commitment with the commitment of individuals and teams to deliver excellent work. We all agree the latter is a great and desirable thing. In this article I am only talking about the former.
Sprint commitment means, that a team of software developers have to commit to finishing a fixed number of stories in the next iteration. I guess the hope often is, that due to the pressure created by such a commitment more stories are developed per time unit. I also heard the reasoning commitment would improve planability of a development project or that it increases the motivation of developers. I think that is all wrong.
There is three main reasons why I think the ceremonial commitment is a harmful concept. Let's dub them the three harms of sprint commitment.
Commitment is based on the team's estimation of stories. Those estimations are, well, only estimations and it is quite probable they are imprecise if not plain wrong. Often enough this is reason enough to give a negative feedback to an otherwise great team. This ignores the fact that any estimation is imprecise no matter how good a team is.
Here is what happens for two example teams:
The result: Team A and Team B did the same great work. Team A is a happy team and starts the next sprint with verve. Team B is an increasingly frustrated team and it starts the next sprint downheartedly. The reason is negative feedback due to sprint commitment.
Commitment makes developers sacrifice software quality by making them hurry to finish their stories at the end of the sprint. The commitment makes the end of the Sprint an artificial barrier. Developers will be tempted to speed up development in order to finish a stories they committed to.
There is only a few ways to reach short-term increase of development speed. Here are two of them:
In our little example It looks like this:
The result: Team A can work on with the usual speed. Team B is from now on hindered by the technical debt it created. The reason is pressure created through commitment.
In our sprints we frequently observe one thing: At the end of the sprint we put a lot of pressure on hurrying stories through QA and signoff steps. In this time of the sprint test-manager and product-owner become a bottleneck. This is annoying for everyone involved. And it is also a direct effect of ceremonial sprint commitment. If we would just finish the stories when they are done, QA work would be much more evenly distributed over the time. This helps to utilize the, usually limited, QA resources much better. This phenomenon has been discussed in depth in the Kanban community.
Let's have a look at our two teams again:
The result: The test-manager of Team A is happily working on one story at a time. In Team B the test-manager has to test many stories at once at the end of the sprint. The QA becomes a bottleneck. As stories are waiting to be tested, bugs are detected lately when the developers are already working on something else. This makes bug fixing more expensive. The reason is an artificial accumulation of finished stories created by commitment.
If you want a forecasting tool, you have one right in your hand: The team's velocity in the past. Just average the last few sprints' results and you can give a rough estimation of what the team can deliver in the future. If you are careful and assume only e.g. 80 percent of that velocity for future sprints, you can give a quite good prediction of when certain features will be available to the customer. There is no precise prediction of the future in agile projects. This is a fact you have to accept. If you can not accept that, you can not work agile. Good look finding a non agile development method that does that for you.
By the way: If you want to know whether or not the work you are doing speeds up, whether you are accelerating or decelerating, you can obviously use the velocity as well.
Yes they are! Sprints offer a rhythm for our work. They help synchronize collaborating development teams. Sprints help to have retrospective meetings to look back on your work on a regular basis. They help measuring the velocity and so allow for an as-good-as-possible prediction of team progress. If you do not do continuous deployment they offer a friendly reminder to deploy to the production system at least once every few weeks.
While sprints have a value of their own, it might still be a valid idea to go without sprints completely and just do continuous everything. I'd love to try that sometime. But that's another story which is told at the campfires of the nice and friendly land of Kanban.
Do you do still do scrum with a commitment? Do you consider a sprint failed that did not meet that commitment? Do you have a fixed set of tasks for your development iterations?
Let me say it with a little joke that Kevlin Henney told in the context of shared mutable state It is of universal wisdom:
Patient: "Doctor, Doctor, whenever I do this, it hurts." Doctor: "Then stop doing that".
Now you know my opinion about commitment and it did not get off lightly. Do you agree with me? What is your experience with sprint commitment? Does it work for you? Do you even love it? Leave a comment below. I am curious about your opinion.
hier vielleicht ein anderer Blickwinkel:
Very true. Plus: if a commitment is reached before the end of a sprint, there is the temptation to slow down until the end of the sprint.
That's a good point Raphael. I did not think about that. Maybe because I did not really observe that in our team. Plus: 3 is a much catchier number than 4, isn't it?
Old article but I steel feel urged to comment. :)
I agree to the second and third harm.
As for Harm 1, I think that if a failed sprint lowers the dev morale, maybe it is not a problem with the word "commitment" but more with the phrase "failed sprint". Especially when people are new to Scrum and less tech savy, e.g. in the role of a product owner that is more on the business end of things, it is probably harmful to call the sprint a failure. Labeling it as such might make the business owners think that the team has underperformed during the last sprint. Maybe just the slight change of simply labeling the sprint as "underestimated" would cause a change in perception with people outside the team, thus alleviating the perceived pressure from the stakeholders on the devs. In my mind the word "fail" lacks the due respect for the teams efforts.
tl;dr: For me, commitment is okay, failure sucks.
Thanks for the input. I think you are right. The wording accounts for a lot of it. Still I believe that wordings like "underestimated" do carry the risk of becoming plain euphemisms for "failure" over time. Thus harm one may still kick in.
Another aspect is that the more your process evolves towards continuous deployment, the less meaning remains in the concept of sprinting. Even less so in the concept of commitment which eventually simply becomes irrelevant.
I agree regarding those harms. To be honest I prefer <a href="http://kanbantool.com" rel="nofollow">Kanban Tool</a>, but you can find quite similar issues there also
great article! I get the impression your article reflects bad experiences with commitment, I see some frustration possibly resulting from waterfall management around the Scrum Team. And unlike you mentioned in your last comment, I think that a commitment is very relevant... even though I interpret it differently.
The way I experienced commitment: Team decides how much they believe they can achieve. After the sprint there can be 3 results: overachievement, underachievement or a landing right on the spot. Imho, the goal of commitment is not to get sth. under control or to put pressure on the team. It's rather about estimating the amount of work in advance in order to look back at the end of the sprint and double check the assumptions that have been made two weeks before. In most cases the assumptions were wrong and the team can reflect on what they have learnt during the past 10 working days. This is nothing bad (!) If you reflect without commitment the reflection is more fuzzy and the effect of learning is smaller. So for me, it's more about constant improvement / learning.
A second aspect especially important to product owners: A product owner wants a great product for the customer. And she spends most of her time thinking about strategy, prioritization and execution of this product. She doesn't always have much time left for thinking about technologies and technical stable & scalable platforms. Is that a problem? I say no. She can rather rely on a strong team that understands that with their commitment, they decide on the amount of functional stories that can be done without risking a technical desaster (or unscalable platform or...). If the team doesn't take this responsibility serious though, quite often the product owner tends to take this responsibility over - despite the (mostly) lower qualification. That's nothing you want for your business... you rather want to focus everyone on their strengths.
Talking about forecasts instead of commitment is just finding other words for the same thing... in the end it's about what you understand about it, not about how it's called. Velocity, there I agree with you, creates the illusion of perfect forecasts (or again... control) - and so far from what I've experienced, it's rather a rough guidance and should be seen just as such.