Hi guys, over the last weeks I have collected a lot of feedback from my readers. One of the topics that people want to see covered is “How To Have An Effective Sprint Planning Meeting”.
For some of you, this might be a basic topic, but as a true Agilist, I must react to my “reader wishes”. If this is a basic topic for you, feel free to skip it ;).
Sprint Planning Meeting
In Scrum, teams plan by picking up Stories from the product backlog. Afterwards, they commit to a set of them for an execution in the upcoming sprint.
Each team plans the upcoming sprint in a time-boxed meeting (like in the most of Scrum Artifacts). By the end of the meeting (outcome) the team will have:
- The sprint backlog, consisting of the stories the team committed for the next sprint. In an optimal scenario, these stories will have acceptance criteria.
- The Sprint Goals
- An agreement by the team to do what is possible to achieve the goals. The word commitment was removed in the last Scrum Guide. In my personal view, this was a great move.
The objective of the Sprint Planning Meeting is to organise the work and define a realistic scope for the next sprint.
Teams agree on the amount of stories they can pull from the backlog. Of course, they must take the availability of team members into consideration. After agreeing on what they will take from the backlog they define the Sprint Goal(s) together with the Product Owner.
Sometimes it is necessary to do some adjustments in order to achieve a larger purpose.
The team capacity is based on story´s complexity, size, and dependencies on other stories and other teams. We all try to get teams to have an end to end responsibility. Unfortunately, the reality is a bit different and it is quite common to have several dependencies towards other teams.
Pre-Requirements for a Successful Sprint Planning Meeting
Before the meeting, the Product owner should prepare some draft of the upcoming Sprint Goals. Usually, part of this task is done in the Grooming session.
Another important part is to be aligned with other Product Owners in case the team has dependencies on others. It is very frustrating for team members when Product Owners come to a meeting asking for work that cannot be done because of external dependencies.
It is not only the Product Owner that must do his homework. Team members must be prepared too. It’s common to have some research tasks (spikes) that must be done before the Sprint Planning. These tasks usually answer questions related to architecture or future implementations.
Guidelines for a Successful Sprint Planning Meeting
Attendees
Attendees of the Sprint Planning Meeting include:
Agenda
An example of a Sprint Planning Meeting agenda:
- The team and PO negotiate and finalise the selected stories
- Everyone commits to the Sprint goals
Meeting
Usually, the Product Owner starts the meeting by reviewing the proposed Sprint goals. During the meeting, the team discusses the implementation and different options. In this meeting, the Product Owner is the responsible to define the what; the team defines how and how much.
During the meeting, the team elaborates on the acceptance criteria (together with the Product Owner) and estimates the effort to complete each story.
Based on their velocity, the team then selects the candidate stories. Many teams break each story down into tasks and estimate them in hours to confirm that they have the capacity and skills to complete them.
As soon the team capacity has been established, the team turns their attention to understanding and agreeing on one or more sprint goals.
The product owner and team agree on the final list of stories that will be achieved. The sprint goals are then revisited and restated. The entire team commits to the sprint goals, and the scope of the work remains fixed for the duration of the sprint.
It is very important to mention that most of the times teams are over confident. They tend to pick more stories than what they were able to achieve in previous sprints. As a Scrum Master challenge them. Usually, they are not going to make it. This can lead to frustration and disappointment.
Hope you liked the post today. Some of you know that I have been studying for the SAFe consultant certification during last weeks. I found a very nice page about the Sprint Planning. I decided to re-write it to make it more look like Scrum :) The original page can be found here.
If you want, leave your comments below :)
Big thanks,
Luis
Leave a Comment cancel
More from our blog
See all posts
Yes, I find it very helpful for the team to have the PO talking about the direction he would like to go for this sprint. Btw, we also do it at the end of the previous Review meeting to share with all stakeholders what should coming next. So by having this direction at the beginning, you can accurately select the stories meeting this mini-vision and when not, you can remind you PO that this story meets no goal. Feel free to add it and adapt your goals. So update your goals during the meeting and at the end of the sprint planning the outcomes should be clear, fixed to everybody to get started :)
Yes, I find it very helpful for the team to have the PO talking about the direction he would like to go for this sprint. We also do it at the end of the previous Review meeting to share with all stakeholders where should coming next. So by having this direction at the beginning, you can accurately select the stories meeting this mini-vision and when not, you can remind you PO that this story meets no goal. Feel free to add it and adapt your goals. So update your goals during the meeting and at the end of the sprint planning the outcome should be clear, fixed to everybody to get started :)
Why I’m developing a Product Owner course is that they are plucked out of the business without Agile 101 and the team does the stuff you describe as their tasks in planning and backlog grooming. We will get there eventually.
@Shahab: Good point. But I think it is good to start with some Product Vision, refine it during the meeting and revisit it by the end, as Luis said.
I have another one: IMHO the Estimations should not be the part of the Planning Meeting. The Product Backlog should have enough estimated Stories at least for the next Sprint, ideally for 2-3. So that the Planning Meeting can be dedicated to the planning only, not the Backlog grooming.
And it also makes sense to divide the Planning into actually 2 meetings: Planning I (What, w/ PO) and Planning II (How, w/o PO).
Will be great to hear your view on it as well.
I think there is a confusion :)
Of course estimation belongs to Planning its one of the mains parts :) You can estimate in the Grooming but should be something much more on High Level :)
Does not make any sense to estimate everything in the Grooming and just proceed to planning and do what you suggested. Most of the times Grooming works as research, team members use the space between Grooming and Planning to actually do research. Only then on the planning they do the final Estimation.
I know a lot of people brake the Planning into Planning 1 and Planning 2 I personally never did it :) I do not have any opinion if its good or not, I just did not find the need :) but I like to keep the PO together with the team until the end :)
Cheers
Luis
Good list :-)
Just wondered why the sprint goal should be discussed and agreed in beginning of the sprint planning?
What happen if things changes during the sprint planning (e.g. discover stories were too big, new story pops up, etc etc)?
Should we then agree on the Sprint goal by the end of Sprint planning again?
I usually leave the Sprint goal to the end of the Sprint planning. Will be great to hear your view on it.
Hi :) Do not be so religious about it ;) this is just a guideline…
If things change during the meeting of course you adapt them ;) But you should start the meeting providing some vision of what you want to do next sprint :)
Thanks for commenting ;)