For the past 4 months, I've been stumbling through the process of leading a cross-functional team working on a project with tight deadlines. So far, I've been faking it well: my manager thinks I'm doing all right.
Among the things I'm still learning is how to run effective sprint planning sessions. I'd like to share some of my observations below.
Have your user stories ready
For me, sprint planning begins a few days prior to the end of the previous sprint. I'll usually have a meeting with our product owner and my manager.
- The product owner presents a list of user stories that we'd like to get done in this sprint.
- We walk through the stories:
- We refine and reorganize any stories that need it.
- We discuss and assign preliminary story points
- We review the sizing total as a sanity check to confirm if the proposed list of stories will fit in the sprint or not (based on prior sprint velocities). Stories are relegated to the backlog if necessary at this point.
Delegate story ownership to your team
In a few of my initial sprints, I spent the weekend prior to sprint planning researching several of the more complex user stories, thinking of edge cases, uncovering potential spikes, etc. This led to sprint planning sessions where there was a fair amount of questions and discussions between myself and the product owner with little or no participation from the rest of the team.
My manager (and former manager --- he sat on one of the sprints) provided me with a useful tip: assign user stories to developers for investigation prior to the start of a sprint. This provides a number of benefits:
- Developers actively participate in sprint planning, especially when discussing the stories they were assigned.
- Developers are more vocal about story point estimations for tickets since they now own those tickets.
- User stories are now being looked at by at least two pairs of eyes (assuming the technical lead is also separately investigating stories assigned out to developers.) This increases the accuracy of story point estimates and reduces the possibility of complexities or questions being missed.
- It prevents the technical lead from being a single point of failure. A consequence of taking on the full responsibility of upfront user story investigation, is that the team lead is the only one who can run sprint planning sessions.. I don't know about you, but that means you're not going to be able to take any vacation at all.
Use remote planning poker tools
In some of our initial sprint planning sessions, we were using Teams Chat as a way to conduct planning poker. This led to an observation where the first estimate typed in Chat appeared to affect other estimates typed afterwards. Wikipedia describes this as "anchoring, where the first number spoken aloud sets a precedent for subsequent estimates."
To avoid this we've now started using online planning poker tools such as Planning poker online which more closely mirror traditional planning poker with features like the ability to display when someone has cast their vote and a button or link to display all the planning cards.
Keep things moving
Developers like to discuss technical details during planning. Product owners like to provide context and additional background tangential to the stories being discussed.
Team discussions are necessary to arrive at better estimates but its important to remain focused and resist the urge to:
- Do a technical deep-dive beyond what is necessary to accurately estimate a user story
- Switch to a detailed discussion about future requirements
In my experience, the first is more at risk of happening than the second (we developers really love our codez!). In any case, I try to keep the team on track by working through the stories one-by-one until we reach the end.
🙏🙏🙏
Since you've made it this far, sharing this article on your favorite social media network would be highly appreciated 💖! For feedback, please ping me on Twitter.
Published