Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Commitment is a promise, and we all have been taught that you need to keep your promises. But is it realistic to keep the commitment for each Sprint? Sometimes people get sick, sometimes the technical approach is proven wrong and you have to rethink everything, sometimes during further discussions with the product owner or the users you understand that the feature should be very different from what was originally thought.

I know that the official Scrum Guide now uses the word "forecast" rather than commitment, probably to address these problems.

So my question is how often do teams in your organizations keep their commitment and whether you like this approach or you want to change it.

Thank you.

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, GlenH7, World Engineer Mar 17 at 14:17

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
1  
A question I've often wondered and two good answers –  Disco 3 Mar 14 at 12:37
1  
If you always meet your commitment, you probably aren't being aggressive enough. Your accuracy will hopefully improve as time goes on, since part of the goal of Scrum is to improve everyone's skills at estimating how long a given task will take in the Real World. –  keshlam Mar 14 at 14:23
1  
@keshlam that's not necessarily entirely true. There's a whole school of thought in the agile movement that's actively trying to move past traditional estimates, recognizing its potential poisonous nature. –  Stefan Billiet Mar 14 at 19:40
1  
Granted, @StefanBilliet... but Scrum's intended to simultaneously de-stress estimates as far as the outside world is concerned while improving a team's internal sense of how much additional work they'll likely to be able to take on when. –  keshlam Mar 14 at 21:12

5 Answers 5

It's not so much a question of how often a team should "keep its promises".
It's more a question of investigating why a team would have a problem meeting its commitments.

If it's some godly intervention, that doesn't really matter. But if you find that you frequently need to return to the drawing board, because your technical approach is plain wrong, or that the PO keeps changing his/her mind, or that stories are not clear enough at the start of a sprint, then you need to investigate why.

Not meeting a sprint commitment is a symptom; you need to be interested in the root cause.

share|improve this answer
    
So should we strive to meet commitment in 99.99% of the cases? If that's the level of needed assurance that the commitment will be met we'll only commit to half of the average work that we can usually produce. So I guess its not 99.99%. So what is it? 50-70%? 80-90%? –  Eugene Mar 14 at 13:17
    
@Eugene Why do you need a number and who needs to be assured? I'm starting to get the idea that there's someone in your organization who'd punish you if you didn't meet your sprint goals... –  Stefan Billiet Mar 14 at 13:35
    
Not at all. In fact in my organization no one cares whether a commitment was met or not. I am trying to change that, because currently fixing bugs and writing tests is left out because there is no time for them. I'd like to advise the teams to commit to less so that they can meet their commitments on a regular basis. But how much less? If meeting the commitment is a matter of life or death then you will definitely commit to less than if it was just a forecast that no one external relies on. –  Eugene Mar 14 at 14:02
2  
By the sounds of it, you have some more fundamental problems. You need to have a team understanding of 'done' before you can measure performance on the number of stories that have become 'done' –  Ptolemy Mar 14 at 14:09

If all is well, then it will be normal for the teams to be meeting their scrum commitments. They should be be running cool enough to cope with small scale, reasonable and likely disruptions such as a days illness, child care emergencies etc... without it immediately and automatically triggering a failure to deliver its sprint commitment. If it can't then in my view the sprints are over committing and are running too hot for their long term good as a team.

If sprints are consistently failing to deliver, then scrum has delivered on its promise, to make 'problems' visible. Problems may include not having properly defined tasks, insufficient experience in the team, or a management culture of continually attempting to over deliver - and so constantly falling short.

Either way, the solution is to identify the root cause, and fix it, rather than whipping the developers harder.

Teams that are always 'close' to meeting their commitments are failing in a more serious way. You can be sure that they are not performing enough testing.

share|improve this answer

I personally believe that if nobody in the organisation cares about meeting your commitment, you are not talking about a commitment. You need two partners to make a deal and to form a commitment.

A sprint commitment is something that you should be able to keep, taking into account all "normal variation". You can read my blog post on basics of agile planning if you want to know more about what I mean with basic variation. And as Stefan stated, not meeting your commitment is a symptom not the disease.

After every sprint you have a moment to inspect the actual velocity of that sprint and adapt your "average velocity" to that (like explained in the post mentioned above). If your velocity keeps going down, sprint after sprint, you start to see patterns that can help you detect the actual root cause of this. This could be too much unplanned work (e.g. small urgent tasks coming in, bugs in the code that you are working on, changes to the acceptance criteria during the sprint, ...). All of this data needs to be tracked, most probably by the scrum master to help her to figure out which patterns are in there. That will help the team to come up with actions during the retrospective.

share|improve this answer

My perspective is that teams aren't making a commitment. Arguably, they aren't even making a forecast. The forecast is made before the sprint is planned -- the forecast is that on average they will meet their velocity. That means sometimes they will do a few more points than their velocity, sometimes they will do a little less.

If you're doing less than your velocity on a regular basis, your velocity drops to reflect that. The forecast thus drops as well. If you keep pulling in more stories than your historical velocity says you can do sprint after sprint, it's not a failure in execution, it's a failure in planning. You know your velocity, so you shouldn't be bringing in more points than history says you can accomplish.

To answer your specific question, of the three organizations where I've used scrum, only one tracked the "miss the commit" metrics over time. For that company, teams typically hit their forecast around 85% of the time.

share|improve this answer
    
Agree. I was on one team where at the end of every sprint planning, the manager demanded a commitment to complete all the stories for the sprint. I fell in the habit of saying "yes" and just continued to be agile. I figured it probably made him feel better that way. –  Rob Y Mar 14 at 18:02
1  
@RobY: I think there's room for commitment in mature teams. In my experience, most agile teams aren't particularly mature, and any PO asking for a commitment is not a good PO. I was on one team that was pretty rock-solid with its velocity and we felt quite comfortable making actual commitments when necessary, but the other teams I've been on haven't been as mature. –  Bryan Oakley Mar 14 at 18:36
    
I was being a little tounge-in-cheek. I agree, there's usually a core set of stories you can commit to, but as you get close to the velocity, it's a little less certain. Since velocity is an average, then by definition sometimes you'll be over, and sometimes under. BTW that same manager would load us up with 2x or 3x our velocity each time and then demand a commitment... so... ;) (I was mostly reacting to your first paragraph, which I think states it really well) –  Rob Y Mar 14 at 20:10

If you aren't meeting your commitment then you should reduce your velocity. If you are always meeting it, you should increase until you fail sometimes.

The issue is how badly do you fail? It should always be close. Either you make it with a little bit of slack or fail just by a little bit. That is a healthy goal for any discipline, running times, weight lifting, etc. Ideally the average amount of work done in a sprint should be a normal distribution around your velocity.

What's more important is the long-term trend in your velocity. If each week you add 15 story points to your velocity but only accomplish 10 more than you did the week before is that really a bad thing? At some places they consider this "stretch goals".

share|improve this answer
    
I really disagree with this answer. Human nature is to try to deliver, and you can bet your bottom dollar that teams will cut 'testing' to deliver, rather than drop the story. If you are always this close to the line, you will not be testing thoroughly enough, and it will come back to bite. –  Ptolemy Mar 14 at 15:39
    
@Ptolemy that is where discipline, professional pride, and a solid "definition of done" are required. Those should prevent you from shipping shit. Also, you shouldn't be counting something as done if you've cut corners. –  ArtB Mar 14 at 16:01
    
That's much clearer on the developer part than it is on the testing part of scrum. You can have no known defects because the tester was focused on testing the core functionality, and didn't have time for 'a random event' that happened to expose the bug. –  Ptolemy Mar 14 at 16:32
2  
@Ptolemy: teams can't technically "cut testing" since testing is part of the story. If they cut it, it's no different than cutting part of the coding. If you omit part of the coded feature, are you completing a story? Likewise, if you cut testing, you aren't completing the story. –  Bryan Oakley Mar 14 at 17:35
    
I've never used scrum but I have made commitments and I have judged whether things are done. It would be nice if the definition of done is wholly objective, i.e. there is no room for the group to interpret the definition in light of whether it needs to be done to meet the commitment. Natural language being what it is, this seems unrealistic. If you're fairly relaxed about the commitment and fairly close to an objective definition this wouldn't be a problem. When Ptolemy says "human nature is to try to deliver", in my schema that means "people are insufficiently relaxed about the commitment". –  Steve Jessop Mar 15 at 0:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.