A deeper understanding on…
The Sprint Planning
Road to PSM III — Episode 17
For each of the four formal events for inspection and adaptation I will share some guidelines, pointers and considerations that helped me in my journey to understanding and practising Scrum. Let’s kick it off with the Sprint Planning.
The entire Scrum Team.
Note though, this is an active, collaborative event. People can fly in and out to look stuff up or work something out if needed. Others can be called in by the Development Team to help. More information could actively be collected during the session itself.
“The Development Team may also invite other people to attend to provide technical or domain advice.” — The Scrum Guide
Not every single member will be as pro-active and creative while participating in the event. Some members will only jump in when they feel confident or comfortable.
A Scrum Master might think it is their responsibility everyone attends and participates. Indeed, poor attendance and participation reduces transparency and introduces risk. However,
“The Scrum Master ensures that the event takes place and that attendants understand its purpose.” — The Scrum Guide
It is my opinion that explaining the value of attendance and participation, whilst enabling a comfortable, enjoyable, calm, and respectful environment is the best way for a Scrum Master to motivate team members to participate.
“Give them the environment and support they need,
and trust them to get the job done.” — The Agile Manifesto.
Sometimes participants can be very dominant and seek to use this event to direct and influence the direction of the team. This input could be very valuable, but it might impede others from adding their valuable input. Participants should be aware about this. In any case, I believe a Scrum Master should step in when team members are being disrespectful or even hostile. A team will look to the Scrum Master as a coach to protect the safety of the environment.
The start of the Sprint.
This was actually a bit of a difficult one to answer. The Scrum Guide isn’t crystal clear that the Sprint Planning has to occur at the start. In fact, if interpreted precisely, the work being planned during the Sprint Planning refers to the upcoming Sprint, not the current or this Sprint, neither does it refer to upcoming Sprint work as it does elsewhere. Remember the Sprint acts as the container for events. The Sprint Planning doesn’t occur in-between, as the Sprint starts immediately after the conclusion of the previous Sprint.
The Scrum Guide does hint at this by telling us that when cancelling a Sprint,
“everyone regroups in another Sprint Planning to start another Sprint” — The Scrum Guide.
Scrum.org’s Scrum Glossary is fortunately a bit more specific:
“Sprint Planning: time-boxed event [..], to start a Sprint.” — Scrum Glossary
It is not uncommon for teams to prepare Sprint plans during refinement. In any case, the Sprint Planning starts on consistent times in consistent places. They start on time.
🕗 How long?
Max. 8 hours for a monthly Sprint. For shorter sprints this is usually less.
It is not uncommon for teams to reduce the time-box relative to a Sprint’s duration. A one week Sprint could have a 2 hour time-box. Remember this is only a maximum time, there is no minimum time. Experienced teams might well be capable to complete the event well before the time-box expires.
Better collaboration and refinement generally results in shorter, more effective Sprint Planning events. That said, a 15 minute Sprint Planning might not quite cut it either.
It pays to have the following prepared for the Sprint Planning.
- Valuable input and feedback from the Sprint Review (may already have been processed into the Product Backlog)
- A refined Product Backlog
- At least one high priority process improvement identified in the previous Retrospective meeting.
- Potential objectives for the Sprint to be discussed
- The definitions of “Done”
- The latest Product Increment
- Past performance of the Development Team
- Projected capacity of the Development Team during the Sprint
Now, I experienced a number of times, and can imagine others have too, members calling to post-pone the Sprint Planning. Either they don’t consider the previous Sprint to be finished, or they consider themselves insufficiently prepared.
Work that is not considered “Done” from the previous Sprint may be replanned into the upcoming Sprint. Remember a Sprint ends when its time-box expires, with the exception of cancellation.
The Sprint Planning isn’t to be postponed in either case. If all of the above isn’t in a transparent state prior to the Sprint Planning, the time-box for the Sprint Planning might allow for this transparency to be created during the event.
Definitions of Ready?
Some teams work with definitions of “Ready”. Scrum only prescribes one definition (though that doesn’t exclude the team from introducing others like INVEST criteria):
“Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.” — The Scrum Guide.
“By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.” — The Scrum Guide
“Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting” — The Scrum Guide (emphasis added)
If this is achieved, the purpose of the Sprint Planning is fulfilled.
To achieve this purpose, the Sprint Planning is split into two parts:
1. What can be done this Sprint?
The Scrum Team collectively aligns on what the Sprint Goal should be. The Product Owner doesn’t dictate the Sprint Goal, but discusses the objective that the Sprint should achieve. This initial exercise creates transparency as everyone aligns on their understanding on the purpose of the Sprint. The Sprint Goal enables a degree of flexibility in what the Development Teams will choose to implement. Sprint Goals may be ambitious (it’s a goal after-all) and promote collective collaboration.
The Product Owner too will discuss the Product Backlog items that if completed in the Sprint, would achieve the Sprint Goal.
The Development Team then creates a Forecast, which is an initial selection of Product Backlog items on what it believes it can do in the Sprint in order to meet the Sprint Goal.
“Only the Development Team can assess what it can accomplish over the upcoming Sprint.” — The Scrum Guide
The Development Team may ask the Product Owner to clarify and renegotiate these items.
At the end of part one, the Development Teams should understand why it is building the Increment.
2. How will the chosen work get done?
When aligned, the Development Team will create an initial Plan on delivering them. This combined is the Sprint Backlog, which will continue to emerge throughout the Sprint.
A friendly reminder: The forecast is not a commitment. The forecast the Development Team created, shouldn’t make them rigid or blind to valuable change. While the Development Team commits as professionals to be doing their best, quality goals should not decrease, neither should a team cut corners on its definitions of “Done” in order to act out the forecast.
The Development Team may already self-organize and undertake the work during this event:
“The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.” — The Scrum Guide
Aside from preparing the input for the Sprint Planning, there might be numerous ways a team may act out this event. It pays off to collectively make visible what the team is working on during the Sprint Planning.
Although it is entirely up to the team to determine how this event is best facilitated, visibility is key.
“Significant aspects of the process must be visible to those responsible for the outcome.” — The Scrum Guide (emphasis added)
“The Product Owner’s decisions are visible in the content and ordering of the Product Backlog.” — The Scrum Guide (emphasis added)
“The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint” — The Scrum Guide (emphasis added)
That said, I would caution against use of digital boards as a means to enable this visibility:
“I’ve seen a lot of ridiculous setups where teams would sit impatiently and inattentively around a table, with JIRA on screen, cringingly watching one person follow instructions to update the board…” — We have to use JIRA
A non-Scrum technique a team could consider is a SWOT canvas on which the team makes important factors that could come into play transparent. Dependencies introduce risk, so they can be tracked during the sprint. Now many Scrum Teams will discover numerous ways on how to best facilitate this event and I’m interested to learn yours.
Naturally, during the Sprint new threats like impediments may be discovered or introduced. The Sprint Planning can help the team prepare for what is known at the time, but perhaps also take into account it will run into yet unknown challenges.
😤 Disagreement and mis-alignment
Alignment, is a purpose for any Scrum Event I’d argue (even though this term isn’t used in the Scrum Guide). Careful inspections enable a team to align on what actually is, so as to develop a shared understanding.
Often, during a Sprint Planning many topics will be discussed. If not all members are present, or the input isn’t transparent, the teams will make incorrect assumptions, have miscommunications and thus be misaligned. It will not be able to make the best decisions, risk is introduced and value isn’t maximised.
At times Scrum Team members will have difficulty in truly aligning on a Sprint Goal, Forecast or the plan on how to approach the work. As with any event it is essential that the Scrum Values are embraced by everyone. Everyone should be able to speak their mind in a respectful way. Different perspectives are learning opportunities.
The self-organising team will learn to work their way through disagreements respectfully. Disagree-and-commit is a potential principle a team can agree on, but this might not suit every team. So there are various ways towards achieving a consensus. In order to quickly detect if there is a consensus a team could for example use hand signals.
When a team can’t agree on how to agree or disagree, this will cause serious disruptions throughout development.
Defining simple first-next-steps is often sufficient. Just get going. Trust you will come to work it out. Remember, it is sufficient to only have work planned for the first days of the Sprint.
🏁 Wrapping it up
As a Scrum Master, try to verify if everyone has understood the purpose and approach of the Sprint and is able to get behind it.
Does the whole team understand how it will collaborate? What is the level of confidence? Are they actually committing or are they silently submitting?
Often a Scrum Master can already somewhat predict, from the vibe at the end of the Sprint Planning, what to expect throughout the Sprint.
Remember, that this is just the start. As the Sprint progresses and more is learned, the plan will have to be adapted and the team might be challenged in its ability to self-organise, meet its Sprint Goal or create its anticipated increment.
Also, as a Scrum Master it is important the Scrum Team is reminded of their improvement goals and that this too is considered when creating the plan.
Remember, the Sprint Planning ends when its time-box expire or sooner if the purpose of the event is achieved.
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.
Do you want to publish in Serious Scrum? Connect with us on Slack to make it happen!