We have found that sprint planning sessions go a whole lot quicker when we know the details of the stories ahead of time, including having architecture discussions and working out any dependencies on other teams well in advance. I can't tell you how many sprint planning sessions have been side-tracked by lengthy discussions about architecture, coding approaches or why the piece of work is more complex than anyone originally thought. Our sprint planning sessions could take 4 hours in the bad old days, even when we tried to timebox our discussions.
Planning ahead without the team
Here's how our process used to work:
- “Next Sprint Goals and Roadmap”
Who: Product Manager and Project Manager
What: Establish the next sprint goal, list the epics in priority order and plan the epics for 3 iterations in the future (headlines only, no detail in the epics) - “Pre-sprint Backlog Pruning”
Who: Product Manager, Project Manager, Lead Developer & Senior SE
What:
- Review next sprint goals
- Review epics in priority order with a view to breaking them down in advance of sprint planning
- Take a realistic look at what’s achievable in the sprint.
- “Sprint planning”
Who: Entire team
What:
- Features are explained by Product Manager
- Team commits to a number of points based on the velocity of the previous sprint, plus any upcoming training/absences.
- Tickets are pre-prepared using templates to include Definition of Done, NFRs, Tests, etc.
- Priority of tasks is reviewed again with Product Mgr.
- Tasks are pointed and anything over the threshold is moved to the top of the Backlog
- Release tickets and load testing tickets are raised.
- Cards are printed out for the wall.
What's missing?
In the weekly "Next Sprint Goals and Roadmap" session, the Product Owner and Project Manager worked out a roadmap detailing several month's worth of planned work and put it all up on a board in plain sight of the team. The thinking was that they could get on with the forward planning without having to take the team away from their work and that the team could then see the headlines that came out of the session. It felt pretty comprehensive and efficient. However, funnily enough....
It turns out that visibility on the wall doesn't translate to a team understanding of the upcoming work.
The team were at a loss as to how we could manage to get "on the front foot" and close the gap between high-level roadmap items and actual, broken-down-and-estimated stories.
It turns out that visibility on the wall doesn't translate to a team understanding of the upcoming work.
The team were at a loss as to how we could manage to get "on the front foot" and close the gap between high-level roadmap items and actual, broken-down-and-estimated stories.
What's missing is the team!
One of the major themes of our Sprint Retrospectives was Teamwork, and how we could achieve visibility of upcoming work. How better to do this than to involve the team earlier in the planning activities?
We gave it a try, expanding the invite to the "Pre-sprint Backlog Pruning" sessions to the entire team.
It worked a treat! Instead of the team first hearing about upcoming work as an email of headlines before sprint planning, and only getting a full explanation at the start of the actual planning session, they began to hear about the stories several days ahead and could have time to prepare tickets and think about their approach.
Now, we're working on ways to increase visibility of upcoming work even further and have introduced a Readiness Board as an experiment.
No comments:
Post a Comment