Sprints, by definition, are a timebox. You’re supposed to say, “Pencils down!” at the end of the sprint, show your work and reflect.
One of the big problems with new-to-agile teams is their inability to finish work inside a sprint. Each team is unique. However, I’ve seen these causes most often:
- Team members multitask, so they don’t finish their work inside the sprint. I’ve seen this when team members multitask across too many stories (too many stories started at one time), and when managers ask team members to work on multiple projects.
- People work as experts, across the architecture, not as a team through the architecture. This cause often creates WIP (Work in Progress). When people work across the architecture, they often create “UI story,” “Middleware story,” “DB story,” and “Test story.” That’s great for resource efficiency. You can show everyone that people are totally utilized. (Yes, a little sarcasm there.) However, software, especially with an agile approach, is about flow efficiency, where people work as a team to finish one story at a time.
- The stories are too large. The team can’t finish one story, never mind whatever they estimated, inside a sprint. Too-large stories have several possible causes. I’ve seen this when a PO doesn’t look for the first possible value in the feature set. I’ve also seen this when teams don’t know the state of the code or the tests and the problem is too complex to finish in less than a couple of months. I’ve written about small stories before. Sometimes, the story is too large because the code doesn’t have unit tests to support changes. You think you can change this little thing over here and bam—it blows everything up.
What can you do if your team doesn’t finish work inside a sprint? Here are the three tips:
- Work as a team. I keep talking about pairing, swarming, and mobbing, and that’s because the team focuses on moving one story down the board, as a team. That solves the too-many-stories-in-progress problem. And, if your manager asks you to work on something else, you can say no. That’s because your team depends on you to work with them.
- Make sure people (especially leaders and managers) understand about flow efficiency. I like to track cumulative flow so everyone can see the inventory of not-yet-finished work. (See the image below.)
- Assess whether this story is one small story or an entire feature set. You might want to use Jeff Patton’s User Story Mapping or possibly Ellen Gottesdiener’s Discover to Deliver. See my series about Product Owners and Learning for more details about how you might consider the planning and workshopping the stories.
This is a cumulative flow chart from a real project. In this project, the PO tried to “get ahead” of the team. He successfully did. He “finished” creating stories the team never developed. I would call that waste.
The team did a pretty good job of workshopping stories (the analysis) part, but had a little trouble with the developers having work in progress.
The developers had WIP because sometimes their functional managers pulled them onto other projects. This team wasn’t so excited about swarming or mobbing, so the managers felt as if they could pull people off.
The entire team (PO and technical staff) had to learn together what a story was. It took them most of this project to get to one-day stories. Part of their problem was that the story “should” have been small. However, they had a legacy code base with very few unit tests. The team spent tons of time creating unit tests to support their work so they could know if their changes were correct.
This team wasn’t perfect—and they didn’t have to be. They found that visualizing their work was critically important to stopping the multitasking and finishing stories. And, once the team got to about the 11th iteration, they had much less WIP.
Here are the things this team tried:
- Track the progress of the story through the team. Track the cumulative flow.
- Visualize any “other” work any team member has while everyone is supposed to work on this one story.
- Select the smallest story you have. Work on it as a team. Yes, work on one story at a time.
You might have to explain to your managers that you are experimenting so you can increase your velocity. Remember that velocity is capacity, and you are learning about your velocity so you can estimate better.
If your team can’t finish work inside the sprint, don’t automatically carry over work to the next sprint. Visualize where the work is, select the highest ranked work, and work on it, one thing at a time, as a team.
Increase your WIP limits only after the team successfully finishes one story at a time. If you need more help, read Create Your Successful Agile Project. Your problem might not be in the stories or teamwork, but somewhere else in your project system.
When teams don’t finish their work in a sprint, it’s a project system problem. That’s an indication the system has to change. Use all your qualitative and quantitative tools (including retrospectives) to diagnose and experiment with your team.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: When Teams Don’t Finish Work in a Sprint: 3 Tips to Seeing and Finishing Work Opinions expressed by Java Code Geeks contributors are their own. |
