Skip to main content

Eight Strategies for Achieving the Scrum Sprint Commitment

I just finished leading an in-house Scrum Product Owner course with a group of 6 actual or future product owners. One of their most pressing issues was what to do when the team does not meet its commitment. "My Team regularly commits to 20 points, then only delivers 10. What can I do?"

We briefly discussed the alternatives of shooting, firing or otherwise punishing team members for not meeting their commitment, but quickly came to the realization that such measures are likely to be counterproductive. If the team fears the consequences of not meeting a commitment, it will be very cautious about making those commitments.

Here are eight strategies for achieving the sprint goal:

1. Yesterday's Weather

If the team finished three backlog items ("stories") for a total of 10 points in the last sprint, then that is a good place to start for the next sprint. As a product owner, only accept a commitment to 10 points. As a team, only offer to take on 10 points. If the team runs out of work, it can always go back to the product owner and ask for more.

2. Smaller Stories

The larger the backlog item, the higher the complexity and the higher the risk. By breaking the story down into smaller stories, you decrease the risk of each individual story. If 3 of 6 stories go South, the Team has a problem, if the team does not succeed on 3 of 20, it's not such a big deal.

Current recommendations suggest that a team should commit to 10 to 20 stories per sprint. For two week sprint with 6 people on the team, that means each story (backlog entry) will need, on the average, about 3 to 6 Person-days to complete.

Reminder: each story must meet the INVEST criteria and have an acceptance test associated with it.

3. Prioritize large stories higher

Even if you are aggressively breaking down stories, some will be bigger than others. It's dangerous to have big, low priority items. When the team starts the story, the sprint should be nearing its end, so the story may not fit. Get the big ones out of the way first, then do the smaller ones.

4. Defend against Scope Creep

A common problem in the sprint is discovering "new" requirements during the course of the sprint. (Product owner says, "check our requirements document, chapter 4.1.3 for the details." Chapter 4.1.3 is where the skeletons are hiding. No-one has really studied the implications of 4.1.3 and it will surely have surprises which cause the effort to rise.

I have found the following strategy to be useful: The story has precedence over the requirements doc. It represents the instructions for this sprint, which is should create a small piece of the entire product. If I stumble on a requirement which is not clearly part of the story, I report that to the product owner, who then decides what to do with the "new" requirement (in backlog or not, prioritized high or low), and I continue to implement the story as previously agreed.

How do you identify what is in the story and what not? Two components define the story: 1) its title 2) how do demonstrate it to the Product Owner at the end of the sprint. If the functionality in question is needed to make the title happen and is visible in the 'how to demo' workflow, then it is part of the story, otherwise not.

Even if title is not a correctly formatted user story, the story should be a complete sentence. For example:
  • Good: As a job hunter, I want to send my resume with my job application so that....
  • OK: Send resume with job application.
  • Much room for improvement: Attach resume.
The second component is "how to demo." This is a simple work-flow which the team will use to demonstrate the story and that they have met the requirements on the story, for instance: 1) chose a want-ad, 2) select "Apply," 3) select "Attach resume," 4), pick file from dialog 5) upload, 6) Send. At there very latest, Team and product Owner should agree on this work-flow during the Sprint Planning.

So the team is working on this story, reads chapter 4.1.3, and discovers 'E-Mails should be signed with PGP to assure authenticity." Sounds like a great, trust building requirement. Is it part of this story? No! There is nothing about digital signing, neither in the title nor in the 'how to demo'. Report this to the PO who can create and prioritize a new story, if appropriate.

5. Strict Prioritization

The backlog items are prioritized in the Product Backlog. This prioritization is carried over into the sprint backlog. A simple approach is to consider the top story 'Must have' and everything else 'Nice to have' until the top story is finished. The team members should always focus on getting the top story finished before looking at issues further down the priority list.

6. Early Acceptance

There is no rule which says the Product Owner must wait until the Sprint Review before definitively accepting a story. If the story is done after three days, then ask the product owner to accept it right away. This smooths out his workload and reduces the uncertainty on how many stories have been accepted.

7. Swarming / Pairing

Consider a team with 4 people, 4 stories each estimated at 10 days each, a 2 week sprint (10 working days), and in which each team member takes on 1 story and works on it large by himself. On the 9th day, each story is 90% done.

How many stories will be done at the end of the sprint? Hard to say. Getting stories done usually means coordinating with other people: a code review, an independent test, acceptance by the Product Owner. This can become a tremendous bottleneck and it is possible that no stories get finished, even if the work on each really was 90% done. The situation gets worse if the stories were underestimated. They don't need 10 days to finish, but 13. At the end of the sprint, nothing is finished and the burn-down chart remains unchanged.

Let us assume that this team applied Strict Prioritization and the entire team worked on one story at a time and that this did not affect the working time needed to complete the story. The first story would finish after 3 days, the second after 6, the third after 9 days. At the end of the sprint, the team has taken 30 points off the backlog. Not the 40 they had hoped, but better than the zero achieved with everybody working on their own story.

Can a team -- and in particular your team -- really apply swarming? Only one way to find out: Try it on a story or two and see how it works. More widely practiced is pairing, in which two team members work on a story together. This is almost always useful, because it stimulates knowledge sharing and prevents becoming too dependent on a single team member.

8. Throttling

The Product Owner cannot and should not tell the team to pair or swarm. But the P-O can still influence this process. Let us assume the team has 6 members. If the product owner only asks for 3 stories (sized according to the guidelines above), then the team is forced to ask themselves, 'How can we work together to solve this problem?'

I recommend this approach to teams that are just getting started, in combination with a few weeks of one week sprints. This helps them learn to do Scrum quickly and to work as a team effectively.

These strategies have worked for me. What other strategies do you use to help your team achieve its commitment at the end of each sprint?


Matt Block said…
Good post and good advice. We've done a few things that line up with these recommendations. My question would be, are they having a retrospective? This should definitely be coming up in the retrospective with an action item or two on what they team plans to do differently the next sprint to avoid this recurring issue.

A few specific things we do...

1) In line with your number 3, we generally leave the sprint planning with the first round of tickets assigned and always ensure the largest ticket(s) in the sprint are being addressed first.

2) We don't really do "swarming", but we do emphasize getting a ticket completely through the process before starting another. When a developer completes one ticket he/she then focuses on peer review and testing of tickets from other developers before starting the next. There are times when the developer picks up another ticket before the first one is completely through due to scheduling issues, but we have a rule of no more than 2 in process per developer without approval from the team in the daily meeting.

The second item above probably had the biggest impact on our success as it helps make it more visible when team members are waiting on others to review or test before moving on to another issue. Kanban practices focus a lot on this "flow" as well and could be very useful to anyone interested.
abc said…
A good posting overall. Could you provide references for this comment:
Current recommendations suggest that a team should commit to 10 to 20 stories per sprint. For two week sprint with 6 people on the team, that means each story (backlog entry) will need, on the average, about 3 to 6 Person-days to complete.
Peter said…
Hi abc,

You might look at this posting on When is a Story too big?" -- in particular the discussions on story size. ( And Sorry for the Spam!! Ugh).

You've caught me on the recommended number of stories - I'm no longer certain where I got the number. I looked for an article discussing the issue and couldn't find one quickly. I will do some research on this and post a better answer to your question.


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…