Sprint planning is the precursor to the sprint. It is an important step as it determines the goals and what work can be achieved in the sprint. It also outlines what can be achieved.
Sprint planning is a whole of team exercise where the whole scrum team work in collaboration to determine what can realistically be completed.
In scrum the sprint is a set of periods of time where all the work is done. Time frames may vary depending on the team however 2-4 weeks are the most likely timeframes. In scrum a sprint is used as it brings large pieces of work into smaller work packages whilst still providing the team with continuous learning and improving.
A number of considerations are required before a team can jump straight into a sprint. You need to decide how long the sprint will be, the sprint goal, the work to be undertaken and where the starting point is.
The sprint planning session starts with setting an agenda. Ideally it is done in an environment that promotes motivation and the team feels challenged with success tied to milestones. A bad sprint will set unrealistic expectations and can have a negative effect on the team with declining motivation and poor work practices.
Sprint Planning Steps Include:
- The What – the product owner reviews the backlog and determines what items will be included in the sprint. The scrum team come together and decide what can realistically be achieved in the sprint and what they can do to make it happen.
- The How – The development team maps out what work is required to determine the sprint goal. The work to be completed is a negotiation between the product owner and the team in determining how to achieve the goal with the capacity the team has at that point in time.
- The Who – it is imperative that the product owner and the development team are at the sprint planning session. It is impossible to effectively plan the sprint if one party is missing. The product owner defines the goal based on the value that they seek. The development team need to decide how they can or cannot achieve the sprint goals.
- The Inputs – it is important for planning the sprint that the product backlog is accessible. This is essentially the master to-do list and will list the items that are required in the next sprint. The team should also look at previous work completed as it will provide guidance on the capacity of the team in achieving upcoming sprints.
- The Outputs – the outcome from the sprint planning meeting is to define a sprint goal and set out how this is going to be achieved. This is made visible in the product backlog.
Prep for the Sprint Planning Session
Planning and preparation are the keys when considering the sprint planning session. The product owner should have in the front of their mind:
- Stakeholder feedback
- The previous sprint review
- Vision for the product
The product backlog should be up to date and prioritised. It is important that the whole team is present as negotiation will be required. The product owner will want to add as much work as possible to the sprint whilst the development team can advise what is practical. The scrum master may need to be the central figure in the negotiation.
Tip 1
It is encouraged that a meeting is held during the sprint that considers the product backlog. This gives the team the chance to step away from the sprint and consider what may be coming up next. This gives the product owner some feedback from the development team who are on the front line and may have knowledge of possible problems or opportunities.
Time Limits
It is a good idea to set a maximum time limit for the sprint planning meeting. This is called timeboxing and sets a maximum amount of time for the team to accomplish a task. The scrum master is responsible for making the meeting happen and that the time limit is understood. If the team is happy with the outcomes of the sprint planning meeting then it is finished. The timeboxing is a maximum amount of time allowed only
Tip 2
Spend the first part of the sprint planning meeting thinking about the objective rather than the detail of the product backlog. By focusing on the goal rather than the work it is possible to find optimal alternatives for how that goal is to be achieved.
Outcomes over Work
During the sprint planning meeting it is easy to get bogged down in the detail of the work. The projects that are being worked on can be complex and the amount of information that is known at the beginning can be low and assumptions may need to be known. Scrum is a process that can be difficult to plan upfront and is characterised by lessons learned and feeding that back into the process.
Having a sprint goal means the objective is clear, however in the meeting assigning the backlog items can also be written with an outcome in mind. User stories are helpful in describing the work from a customer point of view. They re-focus defects, issues and improvements on the outcome the customer is seeking rather than the perceived problems. One way to visualise a user story is to apply the following statement:
As <type of user>, I want <a goal> so that <a reason>
By adding clear measurable goals to the user story, the outcomes can be clearly measured, and you know when they are complete. By bringing together as much clarity as possible the team can be focused and are able to get on with the work.
Tip 3
There is a difference between a lack of clarity and not knowing something. The unknowns should not be ignored as they are the reality of undertaking difficult work. Be clear when you don’t know something and frame the work in terms of gaining an understanding.
Estimating
There is a certain level of estimation required when planning for a sprint. The importance of the team being involved in the meeting helps to define what can or cannot be done. The challenge is balancing the estimated effort versus the capacity.
Getting the estimation right requires a high level of trust, a safe environment where information is given freely, and assumptions are discussed without the fear of criticism. If estimates are used in a negative manner then it increases the likelihood that future estimates are much bigger. To ensure that they are not wrong again the time taken will be much longer. The team may also continue to second guess itself in order to get the estimates right.
Best Practice
It is easy for a team to get bogged down in the detail of sprint planning. The team should be focused on designing a sprint that contains the right amount of work. A good sprint plan will consider what the desired outcomes are and provide a clear plan for success.
A good sprint plan should also provide motivation to the team. This is done by providing clarity and focusing on the outcomes. A motivation killer is when too much work is scheduled and the team does not have the capacity to achieve its goals. If this continues the team may become disillusioned and conflict can surface.
The scrum process is a framework designed to solve complex problems. When dealing with these projects the answers aren’t always known and it is the feedback from sprint reviews and retrospectives that feed into the lessons learned. Recommendations can then be discussed so that the next sprint is a success.
