Want to Close More Stories on Your Scrum Team?
The scrum team’s job is to decide how many story points to bring into the sprint, determine the right stories to accept into the sprint backlog, and close all stories in the sprint backlog by the end of the sprint. Most scrum teams think they know their velocity or how many story points they can complete in a sprint. They also do a pretty good job of prioritization, so they bring in the right stories.
Then, how come so many teams fall short of their sprint commitment? Why is it so hard to close stories?
I could talk to you about risk and uncertainty. I can also advise you on how to reduce risk, but you probably already know the drill. That’s why you already reduce your risk by practicing scrum and time boxing your commitment into a 2-4 week sprint. Good start.
What I am going to talk about is a change of focus.
These 3 changes can dramatically improve your team’s ability to close stories:
- Focus on closing stories not completing tasks
- Take advantage of the benefit of small batches
- Try pair programming
1. Focus on Closing Stories not Completing Tasks
Most teams setup a manual or automated sprint story board to track sprint progress. A typical manual story board is illustrated below:
At the start of the sprint, the Product Owner prioritizes the stories along the left side of the story board and the Development Team identifies the tasks required to complete each story. At daily standup, the Development Team reports progress on the stories and tasks.
A common practice at standup is for team members to report on the status of their assigned tasks in a round-robin manner. This traditional task focus often causes the team to lose sight of the real goal: quickly closing the story.
The key is to change your focus from task to story. At standup, try going round-robin by open story, starting with the highest priority story at the top of the story board. When the team changes focus to the overall status of the story instead of the individual tasks, the entire team has visibility and input to completing it.
2. Take Advantage of the Benefit of Small Batches
Lean manufacturers like Toyota discovered that small batches made their factories more efficient. It seems counter-intuitive that starting and completing one story at a time from start to finish is actually more efficient than every developer on the team opening their own story at the start of the sprint.
The practice of opening fewer stories works because there is less work in progress (WIP). Combine that with the synergy of multiple developers working to complete each story and your team begins closing more stories and improves its burndown.
This concept goes hand-in-hand with the team’s new focus of closing stories.
3. Try Pair Programming
When the team decides to open fewer stories, how do multiple developers constructively work together? In the spirit of self-managing teams, I suggest the Development Team research and learn about pair programming techniques and determine the best way to apply them.
The benefit of pair programming is higher quality code and shared knowledge. The formal definition of pair programming has 2 developers work together at the same workstation, with one developer programming or driving and the other developer navigating or focusing on overall design. The developers can switch roles.
I’m not suggesting that your developers share a single workstation, but I am suggesting that 2 developers can work together, share the work required to complete a story and close the story more quickly.
How many times has work stalled because the developer has questions about requirements? If 2 developers shared the story, one developer could meet with the Product Owner while the other developer starts writing automated tests and begins high-level design.
This is just one example. There are many creative ways we can work together and get more stuff done.
We’re agile.
We’re experimenting.
We’re getting more efficient.
What are some techniques your team uses to increase velocity?
I’d love for you to share in the Comments.
Cynthia Kahn
Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500
You do not go quite far enough on the “Focus on Closing Stories not Completing Tasks” tip. The advice should be to limit WIP. In other words, limit the number of stories being worked on in parallel.
Excellent point. Thank you!
Your advise is accurate. Im in the banking sector, and this prove to be an extremely difficult task. Stories need to be designed vertically sliced, but because of legacy systems, getting a story into Done by the end of a sprint, proves very challenging indeed.
Where I am, very few people on the team have had exposure to Agile and bureaucracy makes agile an interesting challenge.
It’s been a journey the past 5 months, but my agile understanding is pretty solid so I hope to make a difference there :).
Splitting stories up to be vertically sliced whilst keeping them small enough in such a complex environment is not easy, but it drives one to become creative.
Take Care
Thank you for sharing your experiences with us. I think you can make a difference too.