Sprint planning is one of the most important ceremonies in the Scrum project management method. Why run it and how?
Even the Sprint planning ceremony doesn’t seem to be complex, many Agile teams consider it a waste of time.
“Let’s develop something instead of loosing so much time in the sprint planning.”
This is one of the biggest fails of the scrum team. Well, even in case you apply Kanban and not Scrum. Why?
A self-organization
Yes, it is the key to the great Agile team. As Dan Pink mentioned, authority, purpose, and mastery are the best inner motivation drivers.
The sprint planning ceremony helps the team understand the purpose of the Sprint, identify how their mastery can grow up and have a feeling of authority to plan and manage professional life.
If the Sprint planning is done well, it leaves the feeling of known targets, the direction, and the strategy of how to reach them.
The Sprint planning agenda
The sprint planning session starts with the product owner who introduces sprint goals to the agile team.
How long should the planning be?
The first few sprint plannings take typically 4-6 hours. Maybe it sounds too long and so it is. But it is due to the learning, forming, storming, and norming that the team needs to build up. After a few such plannings, the sessions will be shorter and shorter.
Two hours are pretty fine for effective sprint planning session.
In reality, great agile teams are already aware of sprint scope in the sprint planning as they held sprint pre-planning sessions in the previous sprint. There were user stories prepared or questioned enough to find user stories that are not ready and can’t be slotted to the next sprint without further elaboration.
Some teams mark them as ready and estimate story points.
With the sprint backlog prepared that way, the team can focus in the sprint planning session on the breakdown of user stories into subtasks, estimate them or assign them (if it is wanted). Plus evidence them in an electronic tool.
Tip: Always prepare the Sprint backlog and subtasks on physical Kanban board first to concentrate on the solution and building up agreements in the team.
Once you are done, write them into an electronic tool. It is much faster approach as you do not loose a time on the tool, but on brainstorming itself.
This is how planning can be definitely done in two hours.
How to prepare for the Sprint planning
Before the Sprint planning the Product owner should:
- Check the product roadmap and choose the best features to be delivered.
- Consider all changes, defects, and support cases that appeared before the next sprint. In ScrumDesk our principle is to clean up the mess caused by defects as soon as possible therefore I as the Product owner prioritize them as the first items in the new sprint.
- If you support multiple stakeholders, check the changes of priorities with them before the Sprint pre-planning. Do that in one room with all of them so they can align priorities together.
- Validate user stories readiness. Use the definition of ready your team built up.
- Do business prioritization before the Sprint planning so you are sure about an order of cards in the Sprint Backlog. Use Moscow, business value, and risk for ordering.
- Prepare acceptance criteria. I used to even mark as mandatory, should, and could so I am the first who prepare for simplification of the features even before the team touches them.
- Collaborate with UX designer to provide all designs needed for the Sprint user stories.
- And last but not least. Ask your ScrumMaster for feedback on how the Sprint backlog is prepared. He is your advisor!
When to evidence the Sprint backlog
If you use an electronic tool, you probably have your sprint backlog ready in the tool. And that is perfect!
But for the Sprint planning, if your team is collocated, always print out the cards. Let the team brainstorm user stories, not just to observe or play with the tool. They are in the workshop to create a plan together!
Once all user stories are broken into subtasks and they are estimated, only then all team members should rewrite tasks into the tool. Not just ScrumMaster.
It is an agile team’s work, they should do that. The product owner should add Acceptance subtasks.
Typical mistakes
- The ‘Ohhhhmm’ product owner pulls user stories from the Product backlog story map into the sprint backlog in the Sprint planning session in front of the team. They are bored and just waiting for PO.
- The team sees the sprint user stories first at the planning. They need a lot of time to understand them, the discussion is endless, new cases are found too late. The team doesn’t come to conclusion, they feel like scissors are opening wider and wider.
- The team doesn’t check the definition of done so some subtasks are missing at the end of the planning. The Sprint Backlog is not consistent and forgotten work is recognized at the Sprint review. Many times such forgotten work is even not recognizable as team members didn’t add subtasks during the Sprint, just made the remaining time longer than estimated.
- Subtasks are not estimated thoroughly. What you will find are numbers like 0.5, 2, 4, 6, 8.
- ScrumMaster evidence all the work into the electronic tool. As there might be hundreds of cards, he will not be able to finish that on the first day of the Sprint and start the sprint. The burndown chart will be shifted and not display the real value for a couple of days. Which is very often a real-life case. The team is therefore blind for that time.
- The items are not discussed with stakeholders. The priorities do not agree with them. They are not happy about missing items and therefore they will start to change the planned sprint soon.
- A lot of ‘research’, spike, or ‘Analyse User stories’ indicate an unready sprint backlog. Try to start to work on the items of Sprint+1 or even Sprint+2.
- Getting through subtasks is very fast. The team does not have the patience to discuss the solution. This is a reason for many discoveries later in the sprint. The work is slower than expected.
- I’ll implement it faster than explain it here. You just blocked knowledge sharing and the self-organization of your team.
- No moderator, no agenda, just do it. People are not concentrated enough, there are no breaks, everybody just wants to finish it.
