The Scrum Planning Meeting – doing it right

In this article I want to share with you my experience with the Scrum Planning Meeting. Maybe you will find them interesting enough to try on your own. These practices are safe to failure. Applying them cost you nothing but a little perseverance. Enjoy and share more practices in the comment section.

In Scrum, every Sprint (iteration) begins with a Sprint Planning Meeting. This meeting has one basic goal, creating a list of user stories which will be delivered in the next sprint. Of course, requirements may also be presented as features, scenarios, etc. I always use user stories, but these rules can also be applied to different types of requirements.

Looking from my experience, it is the most difficult event to conduct in the whole Scrum Cycle. Product Owner and Development Team have to work together to combine a Sprint Backlog.

The Sprint Backlog is an agreement between Product Owner and Development Team. Developers agree to meet certain goal in time-boxed sprint. That is why it is so important to have everyone focused on this meeting. Badly conducted Planning Meeting will have an impact on the whole Scrum Team.

Be prepared. Have your goal.

Product Owner starts preparation to the Scrum Planning Meeting even several days earlier. He has to gather all user stories from stakeholders. Unprepared Product Owner without prioritized Product Backlog is a very serious problem. Wasting developers time is no fun. Product Owner has to know what the most important features for stakeholders/business/team/etc. are a they can vary according to the project. Sometimes priority is enforced by a Scrum Team because specific user story comes from the Scrum Retrospective Meeting and sometimes stakeholders need one feature because they already promised that to their clients.

Product Owner has to know the goal for the next Sprint. Good practice is to share that goal with everyone, even write it on a whiteboard and make it as clear as possible, due to that everyone can commit to it.  All requirements should results from that goal, which helps everyone to be focused on it. Even if some priorities are not clear or “everything has high priority” (from where do I know that?), common goal can make The Sprint Planning Meeting.

Have your goal

Make it timeboxed

All events in Scrum are timeboxed and the Sprint Planning Meeting is not an exception. It should take no longer than one work-day per month long Sprint. From my experience I know that sometimes Scrum Team forgets about that; they discuss every small detail and meeting takes forever. Add not clear goal and The Sprint Planning Meeting can lead you to nowhere. Scrum Master has to keep an eye on time and should remind the whole Scrum Team of their limited time.

Few words about estimation

If you are not familiar with estimation idea, please check Marcin Drobik’s post about Software Estimation. Estimation is very important (if not the most important) in Scrum. The Scrum Team uses estimation during the whole project to plan work not only in a single sprint, but they can also use that capacity as reference in future sprints.

I focused on point estimation as it is the most popular way of estimating user stories in Agile projects.

Estimation in points has to meet two requirements:

• Points have to be clear for everyone
• They have to be ideal and abstract

Business always wants to calculate estimations to time and money. When team has agreed more abstract values it is easier to work on solution and not only fight with each other about hours. Using abstract values is important also from two other perspectives, namely you can include complexity and doubt in your estimation. This allows you to capture more effectively source of variation than hour-based estimates.

Golden triangle of estimation

The most basic estimation type is the Fibonacci Sequence. The simplest user stories would have one point, the most advanced, difficult ones or those with the highest level of uncertainty – the highest value. What is important and what you should remember during estimation is relationship between user stories.

However, often there are people who want to interfere with your points and they will compare two Scrum Teams based on their estimations. You can ignore them or… you can change your approach. You can start estimating in T-Shirts sizes. That way you will have S, M and L size and you can always add XS and XL or even XXL if you want. If T-Shirts are not funny enough, you can estimate in animals. Try to finish one elephant, one goat and three squirrels in one sprint… and then try to compare them to 20 points. It is almost impossible and your planning meeting can be very entertaining.

Animal estimation

Make planning more engaging

Now, when you have your individual story points, you can start estimate. And here comes next common mistake. Normally, developers estimate one after another, which at the beginning is great. Estimates differ and there is a lot of discussion. After few rounds they are stabilizing… but are you sure? Maybe people are just tired and they repeat estimates after first few people? You will not know…

But there is a solution. You can use planning poker. That way everyone selects one estimated value and then all cards are revealed in the same time. Are they different? Then let developers explain the lowest and highest values. Due to that you will be certain that everyone understands user story the same way – there are no mistakes or, no one under- or overestimates the user story. Let them play second round. Now you can be almost sure that estimations are correct and the whole team identifies with it. This is the simplest way to keep everyone involved. You can use normal playing cards or get dedicated ones. It doesn’t matter as long as everyone understands their purpose. You can also add few more cards to your deck – with coffee or time symbol. If someone is burnt out, you can have a break  to recharge and resume your planning after few minutes when everyone is fresh again.

Example of Planning Poker cards (source: www.it-zynergy.com)

Divide and conquer

Remember your last stand up? Someone told that he worked on user story X again? This is the third time already! When will he finish?

Looks familiar? I bet it does! User Stories are often just too big to be finished in one day. What to do when you have epics and each of them takes whole sprint to finish. In that case one developer may work on the same thing on all Daily Scrums (there can be more reasons, why developer is coming on Daily Scrum with the same information over and over again, but here I do not focus on all of them). It can be annoying and frustrating, but it is not his fault. Of course he can be more specific on Daily Scrum about his work, but this problem can also be fixed on the Sprint Planning Meeting!

This is because you did not perform your planning session well. The Sprint Planning Meeting has two parts:

• What will the team do?
• How will the team do it?

Answering both questions is crucial. Until now we spoke only about the first part. We selected user stories for the sprint by estimating them and we created a Sprint Backlog so it looks like we finished our work.

Nothing more wrong! The second part of the Sprint Planning Meeting can be very enjoyable for developers. Now they can discuss how they want to finish user stories – what has to be done in order to deliver them. That way Development Team can select several tasks from one user story. Of course, portioning tasks from very small user story can be considered as pointless but it shouldn’t be totally true. Development Team can learn different parts or developed project from that information.

Breakdown user stories

Summarize your meeting

Remember that each meeting has to be summarized. For the Sprint Planning Meeting, good summary is a Sprint Backlog. It should be result of your hard work. If the Sprint Backlog is portioned to tasks – it is even better. A Sprint Backlog is not the only result of that meeting.

I always finish meeting with Point Board. It looks pretty the same as a Sprint Backlog, but there is one important thing added to it. I order user stories by their weight to show relation between them. Stories with the same estimation should be close to each other in some way – it can be difficulty, effort needed to finish them or uncertainty. That way, team can review their estimations, check if one user story is “bigger” than other, and correct these estimations if needed (in that case further discussion is normally needed). Of course there are also two additional relations – between neighbors. Everything is displayed on below figure (Fig. 5).

By showing them to the team, I let everyone know that this is their work and everyone should feel that it is valid, that values are proper for these items.

Relations on Point Board

I hope you enjoyed my entry and your next Sprint Planning Meeting will be better than the previous one. There are more ideas of conducting this event – I tried to show you the ones I used and succeeded. If you have more – please share your experience in the comment section below. If any idea requires clarification, then also add your comment. I did not want to write the whole book about them.