I love seeing a team finish more work than expected in a sprint. It’s always exciting to have so much new functionality to show off to our stakeholders.
However, I also want to ensure that the work completed allows us to keep moving next sprint. Unfortunately, we can have a great sprint on paper and still inadvertently leave important work blocked for the next one.
Planning a sprint takes more than pulling in enough story points to match the team’s velocity. The more tracks of work a team has going at once, the more there is to coordinate. I often feel like Charlie from It’s Always Sunny in Philadelphia when arranging all the pieces.
Velocity Only Tells Me So Much.
When a team has several tracks of work going at once, the overall numbers can look good while one area falls behind. One track finishes more than planned, another finishes less, and the total comes out looking pretty healthy.
But those things don’t necessarily cancel each other out. If the track that fell behind contains a prerequisite for next sprint’s work, we have a planning problem. The extra work completed elsewhere might be valuable, but it doesn’t unblock the work planned for next sprint.
This is why I always dig into that total. Which work moved forward? What’s still waiting? Does the team have what it needs to keep going without any efficiency hiccups?
But … We Already Have a Roadmap?
I know what you’re thinking: isn’t that what a roadmap is for? Yes, a roadmap helps us put the bigger pieces in order. For example, it might show that data import needs to come before reporting.
Reporting might depend on one specific piece of the data import work. Finishing that ticket could let the reporting track get started while the import track continues with other work. If we complete several other import tickets but leave that one unfinished, reporting stays blocked. We’ve delivered useful functionality, but missed the piece another track needed.
When I’m choosing work for a sprint, I always look ahead at what the team will need for the one after it (and after that one).
Plan for What Comes Next.
Before I choose work for a sprint, I look at what we expect to start in the one after it. Then I work backwards: what needs to happen now so that work can start? It’s simple, and pretty obvious, but can be easy to forget when just trying to keep the velocity train moving.
I also include dependencies beyond a specific feature being implemented. A client decision, an updated design, system access, or data might need just as much lead time as a ticket.
These are the questions I work through:
- What do we expect to start next sprint?
- What could prevent that work from starting?
- Who needs to provide or finish each prerequisite?
- When do we need it by?
This can change which work we choose to pull in. A small ticket might need to come first because several other pieces depend on it. An independent feature might be able to wait, even if we could finish it quickly.
Give the Small Things Bigger Credit
The work that prepares the next sprint isn’t always exciting to report. Getting a decision confirmed or a data format agreed upon may not make for much of a demo, but if it allows several people to start their planned work, it matters to delivery.
Keep celebrating the features, the fixes, and the strong velocity. When choosing work for the next sprint, check which tickets will let other work get started.
Are we making room for the things the team needs next?