Sprint planning involves the Product Owner and Developers. The Product Owner comes to the meeting with a set of features desired to be developed in the upcoming iteration. Developers must come up with a plan on how to implement those features into working software.
Scrum master supports Sprint Planning Meeting by helping the Product Owner and the Developers to plan a valuable, balanced and secure iteration. The scrum master can lead the preparation phase, facilitate the meeting, watch for improvements and make sure that the sprint plan will bring the scrum team closer to business goals.
There are things You as a scrum master can do before and during the meeting to help the scrum team to plan the most effective sprint.
Gather inputs
To help with the planning You need to gather some data in advance.
- The history velocity of the development team with an average of 3 to 6 sprints. It is best to have the velocity data from sprints in which the development team was in the same composition. It is important to track these data regularly.
- The history of unplanned work that was added to past sprints.
- A forecast of probable unplanned work that is probable to be added to the upcoming sprint if such forecast is possible to acquire.
- Planned absence of developers in the upcoming sprint.
- User stories
- Unfinished tasks from previous sprints that require completion
- UX/UI design if available.
Calculate capacity
Developers must know how many tasks they can take for the upcoming sprint.
The scrum master can help by calculating the capacity of the sprint based on gathered inputs – average velocity, possible unplanned work for buffer estimation, and planned absence of developers.
If the team uses story points as a unit for estimating tasks then the capacity can be simply calculated. The story points must be unrelated to the time that will be spent on doing the work. I described how to do it in one of my previous posts: How to calculate the capacity
Product backlog ready for planning
Product Owner must know the most important product features to develop.
Based on business analysis product owner defines user stories.
Backlog refinement is an event that takes place before the sprint planning. At this meeting, developers familiarise themself with the most important user stories and begin to decompose them into tasks. Refinement is preparation for sprint planning and is very important for effective and realistic planning.
During refinement, developers can encounter some significant technical problems. You as a scrum master can help by inviting to the sprint planning domain experts that will help the team with finding proper solutions. It can be for example a system architect. You can also meet again before sprint planning to find a solution and be prepared with a decomposed backlog.
After good refinement, the scrum team has a product backlog ready for sprint planning.
Facilitate
Lead the meeting in the beginning.
Make a quick introduction summing up the past sprint.
If one of the retrospective topics concerned the sprint planning – remind the scrum team about any decision that was made.
If someone new comes to sprint planning make a broader introduction. Remind why good planning is important – predictability, balance, and progress towards product goal.
Draft sprint goal
This should be the moment that a product owner takes over. If nothing changed since the backlog refinement meeting a desired goal for the upcoming sprint should be easy to set initially. The product owner should remind the development team about user stories to plan. The scrum team should start a discussion about the backlog.
As a scrum master, it is good to step a little back at this moment so you can observe and note how the developers interact with the product owner.
If the team asks you to take over JIRA or any other system for task management you can help them with it. You must make it clear that this can’t be a rule and they must learn to do it themselves.
If the product owner doesn’t really know how to lead the planning meeting you as a scrum master must work with him and prepare him during a different meeting. Also during the planning, a new product owner will probably need your help so you should be ready to give him a hand.
The drafted sprint goal will be a benchmark and will guide the team during the rest of the planning.
Check the alignment with the product goal or team PI objective
The business representatives on a higher level set priorities accordingly to the strategic direction of the product and the whole organization.
The team needs to address those goals with work in sprints. It is good to remind the scrum team about those goals during planning so they can adjust the work if needed.
Decompose user stories
The developers should decompose user stories into smaller backlog items. Some of the work was probably done during the refinement but there is still some work to be done for sure.
Developers should discuss every aspect of how they intend to develop every functionality that is requested.
A comprehensive approach is needed as after the sprint is over the functionalities should be ready for a potential release.
Estimate tasks
The development team should estimate tasks in order to load the sprint. They shouldn’t exceed the calculated capacity.
Every member should actually take part in the estimation process.
From my experience, developers don’t want to discuss issues that are beyond their expertise. It is best when every competency is at least doubled. For example, there are two back-end developers in the team and they can easily discuss back-end-related tasks.
For estimation, the team should consider the complexity of a task, its uncertainty, and labor intensity.
Make sure the definition of done is set on the tasks. It is important to agree on how to implement the feature and when the work will be ready for acceptance testing.
Planning poker is one of the tools that developers can use in order to use the strength of the group to estimate tasks.
Scrum master should teach the team how to play planning poker and facilitate the “game” if needed.
Everyone must understand what the issue is about. Then everyone thinks of a value in the story points scale and prepares a card. Everyone exposes their choice on a signal. If there are extreme values they should be discussed – why does someone give a little number or a big one. If there is any relevant information given by someone during the discussion the voting is repeated.
There are scrum cards available for in-person meetings. Also mobile applications for smartphones or web apps like Scrum poker online for dispersed planning.
In many cases scrum poker is unnecessary but it is a good tool to decide on a value for a complex issue in a big team.
Ensure balance between business goals and teams velocity
As a scrum master you calculated the capacity right. The team can’t plan more – it has no sense.
If they do – the sprint won’t be predictable and that is something we don’t want.
A conflict between product owner and developers is common. It doesn’t mean that they are fighting but they have different interests when planning the sprint.
The product owner wants to develop as many functionalities as possible.
The developers want to focus on fewer things and do them right.
It is scrum master’s role to ensure that the product owner doesn’t stress the team too much. Also, the team should not take too much space to overthink issues.
If we want an effective and predictable team then we need a balance between the product owner’s desires and the developer’s commitment.
Buffer
Every sprint needs a buffer for unplanned work.
Buffer’s size depends mostly on what the team does besides the development of new features.
- Is their app in the production phase and there are possible bugs to appear?
- Were there many bugs so far? Is it an old and well-established application?
- Is a very difficult refinement waiting in the coming sprint?
- Is a release coming and unknown complications are possible?
The team usually focuses on planning only. Scrum master supports sprint planning meeting with a reminder of such situations.
It is the responsibility of a scrum master to be able to help the team to make the right decision.
At this meeting, the right decision is to plan as many issues as they can deliver and leave space for any unplanned work that can occur.
If no additional work appears during the sprint it is no problem to add some work that wasn’t planned at the sprint planning meeting. There will always be tasks in the product backlog, some unit tests to write, code refactoring, and others.
Load the sprint
At this point, the scrum team discussed every piece that was brought by the product owner.
Everyone is tired.
It is the scrum master’s role, to sum up, what is planned so far.
Take a look at the sprint backlog and ask the scrum team the following questions:
- does it feel overloaded? – if so discuss what can be removed from the scope,
- does it exceed the capacity? – if so discuss what can be removed from the scope,
- is there a buffer? – if not discuss what can be removed from the scope,
- do the planned issues address the drafted sprint goal? – if not maybe we should set a different goal or plan different tasks
- Is there still space for additional work to plan? – if so check for any additional work to enter the sprint or leave this space as a buffer
- does the planned work addresses the product goal or team PI objective? if not make sure that this spirit scope won’t negatively affect the product roadmap or team PI objectives can be achieved on future sprints in this PI
- does everyone understands what needs to be done – if not provoke discussion about any doubts that were signalized so everyone is on the same page
Set sprint goal
When everything is planned the sprint goal must be set.
Its definition should be precise, clear, and understandable to everyone. It can be written as a milestone for bringing value to the user.
The sprint goal will focus the team during daily scrums.
Start the sprint
Buckle up!
If no one has anything more to add…
It’s time to fly!
Start the sprint and deliver some great value!
In conclusion
“If you have failed to plan, then you have planned to fail”
