10

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.

Eugene
  • 1,943
  • http://meta.programmers.stackexchange.com/questions/6483/why-was-my-question-closed-or-down-voted/6491#6491 – gnat Mar 14 '14 at 08:43
  • 1
    A question I've often wondered and two good answers – matt freake Mar 14 '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 '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 '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 '14 at 21:12

5 Answers5

21

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.

Stefan Billiet
  • 3,547
  • 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 '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 '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 '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' – Michael Shaw Mar 14 '14 at 14:09
13

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.

Michael Shaw
  • 9,935
  • 1
  • 24
  • 36
4

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.

Community
  • 1
talboomerik
  • 41
  • 2
2

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".

Sled
  • 1,868
  • 3
  • 17
  • 24
  • 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. – Michael Shaw Mar 14 '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. – Sled Mar 14 '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. – Michael Shaw Mar 14 '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 '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 '14 at 00:19
  • Therefore define you're definitions numerically. X% line coverage, y% branch coverage, Z integration tests, and sign off by the product owner. Don't give yourself the wiggle room. Also, be willing to fail sometimes. An irrational fear of failure will make you do dumb things that'll hurt you in the long run – Sled Mar 15 '14 at 02:32
  • @bryan Testing is always a judgement call. You can always think of an additional test to perform, likewise testing is rarely done with infinite time, so you prioritise tests on the 'expected' use of the software. What about unexpected things? You can never test them 100%. Testing is a judgement call between likelihood of finding a new defect vs time spent delaying product release that is 'good enough'. When time is under pressure, the first thing to get squeezed is testing time on EVERY team I have worked with. – Michael Shaw Mar 17 '14 at 09:57
  • @ArtB: I don't know what "Z integration tests" means exactly, but the other two don't demonstrate that the tests are correct, they demonstrate that the tests run all the code under test. Therefore they leave enormous scope for someone to do sloppy work to meet a deadline, which is precisely what the question is about. But I take your point about sign-off: if you define that satisfying QA is sufficient for "done" then you take the interpretation of "done" entirely out of the hands of the people involved in the sprint -- is that a typical Scrum practice? – Steve Jessop Mar 17 '14 at 17:46
  • By "Z integration tests" I meant "Z number of integration tests". I think ultimately you need your developers to have the backbone to stand for quality and have a firm definition of done that they can point to and say "No, we cannot meet all my criteria for completeing this task to our standard." If your developers cannot do that then you cannot help them since there will always be a pressure to be done sooner. If you can't trust your developers to speak up then the problem you are dealing with is indistinguishable with preventing fraud. – Sled Mar 17 '14 at 18:29
2

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.

Bryan Oakley
  • 25,332
  • 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. – sea-rob Mar 14 '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 '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) – sea-rob Mar 14 '14 at 20:10