How to prepare for Sprint planning well

Sprint planning is one of the most important ceremonies in 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 as a waste of time.

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 for the great Agile team. As Dan Pink mentioned, an 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 strategy how to reach them.

The Sprint planning agenda

The sprint planning session starts by 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 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 session in the previous sprint. There were user stories prepared or questioned enough to find user stories which 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.

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:

1. Check the product roadmap and choose the best features to be delivered.
2. 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 first items in the new sprint.
3. 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.
4. Validate user stories readiness. Use the definition of ready your team built up.
5. 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.
6. 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.
7. Collaborate with UX designer to provide all design needed for the Sprint user stories.
8. And last but not least. Ask your ScrumMaster for feedback 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 to 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 agile team’s work, they should do that. The product owner should add Acceptance subtasks.

Typical mistakes

1. 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.
2. 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.
3. 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 estimation.
4. Subtasks are not estimated thoroughly. What you will find are numbers like 0.5, 2, 4, 6, 8.
5. ScrumMaster evidence all the work into the electronic tool. As there might be hundreds of cards, he will not be able to finish that in the first day of the Sprint and start the sprint. The burndown chart will be shifted and not displaying the real value for a couple of days. Which is very often real life case. The team is therefore blind for that time.
6. The items are not discussed with stakeholders. The priorities are not agreed with them. They are not happy about missing items and therefore they will start to change planned sprint soon.
7. A lot of ‚research‘, spike or ‚Analyse User stories‘ indicate unready sprint backlog. Try to start to work on the items of Sprint+1 or even Sprint+2.
8. 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.
9. I’ll implement it faster than explain it here. You just blocked knowledge sharing and self-organization of your team.
10. No moderator, no agenda, just do it. People are not concentrated enough, there are no breaks, everybody just wants to finish it.