A Sprint Planning Template
To help you run a more effective Sprint Planning driven by a realistic Sprint Goal
As a Scrum Master, I am always cautious about using templates, especially elaborate ones with lots of graphics and steps. I worry that the template will end up being a distraction to the team, interfering with their focus on the actual goal of the session. I much prefer to help them internalise the principles, so that they can shape the events themselves.
Individuals and interactions over processes and tools
- first value of the Agile Manifesto -
That is not to say that I don’t use templates at all. But I tend to use them sparingly and very much after carefully considering the state of mind of the team I’m working with. I find that many developers do not appreciate all the frills and psycho-stuff we Agile people bring with us. They would rather just get business done so that they can get back to building cool stuff!
Sprint Planning
Sprint Planning is in my experience one of the hardest events in Scrum. It not only consists of a variety of different subjects that need to be addressed, but these subjects also depend on each other and the order in which they are addressed matters a lot.
So for example, even though we might draft a Sprint Goal at the beginning of the session, a later discussion about scope may force us to re-evaluate the Sprint Goal. An even better-known effect is the practice of collecting PBIs before defining a Sprint Goal, which usually results in the team focusing all their creativity on trying to find some ‘goal’ which summarises all the selected PBIs, instead of focusing on finding a Sprint Goal that delivers the maximum value.
The Sprint Planning is also hugely important because it is the moment that the two main feedback loops in Scrum are assembled: the delivery feedback loop, ending in the Sprint Review, and the way-of-work feedback loop, ending in the Retrospective.
My approach to Sprint Planning is to take the team step by step, starting from the Product Goal, defining the Sprint Goal, putting the Sprint backlog together and finishing by formally starting the Sprint. I’ve always thought the steps we take are quite obvious — a logical and effective sequence. So my expectation has always been that the team would eventually pick it up themselves.
However, recently I’ve begun to realise that this may be an over-ambitious approach, putting too heavy a cognitive load on people — developers — who are usually much more interested in getting the event over as fast as possible and getting back to building cool stuff.
That realisation has led me to design a Sprint Planning template which provides a team with all the steps which I find valuable to making Sprint Planning effective.
The Sprint Planning Template
So here it is, the Sprint Planning Template. Available on our own Scrum Facilitators GitHub, where you will find a pdf and a png, as well as a manual and more information. There are also both a Mural template and a Miro template.
The template is split into 3 stages.
Sprint Goal
The first stage focuses on crafting an effective Sprint Goal, with a clearly defined value and an explicit measure to determine when the Sprint Goal has been delivered. This step provides the context for the next two steps.
Note that although not mandatory, a good Product Goal will help a lot in this first stage. For a team to be effective, it needs a higher goal, some North Star to focus their efforts: the purpose in Daniel Pink’s key components of intrinsic motivation.
Specifically for Sprint Planning, having a Product Goal will make it easier for a team to understand the value of a Sprint Goal, and how it fits in the bigger whole.
The Plan
The second stage covers developing a plan to deliver the Spring Goal. Here we collect tasks — all activities that deliver something concrete towards achieving the Sprint Goal. And we consider obstacles, which will usually result in new tasks specifically to address those obstacles.
Throughout, we continuously adjust and clarify the scope of the Sprint, adding post-its to the red section to clarify what will not be done during the sprint. Talking about scope usually also starts a conversation about whether the team actually has the capacity to deliver the tasks. Here the out-of-scope area seems to make it easier for the team to decline work, as it provides a parking place: a task may be removed from the sprint, but in the our-of-scope area it is highlighted as something to pick up in the next sprint.
Note that I’m talking here about tasks and not PBIs. At this stage, I prefer to have the team focus on “what needs to be done”. This encourages creativity and a more complete view of how to achieve the Sprint Goal.
This helps the team to consider things that may not be formal PBIs but which may be important in preparing an effective plan for the sprint. Think for example about things like preparing a meeting with another team to discuss a dependency, an important milestone or a reminder to invite stakeholders to the Sprint Review.
Once the tasks have been collected I like to have a separate moment to translate the tasks to proper PBIs. That way the team can separate the creative process from the more formal process of composing PBIs, perhaps using a tool such as INVEST.
Tasks that are not formal PBIs can be used to populate the timeline.
The Timeline
The last stage consists of an approach that I find very useful: creating a timeline to visualise the Sprint plan over time. I find that just having a Sprint Backlog makes it challenging for teams to manage the Sprint. A collection of PBIs to be delivered by the end of the sprint is not usually an effective plan.
A timeline helps the team to envision how they expect the work to progress over time. With the timeline I see teams breaking the sprint up into phases. And it also helps as a place to track other things that might affect the Sprint, such as the non-formal tasks we discussed above, and things like holidays. In fact, the timeline is a perfect place to track anything that cannot be added to the Sprint Backlog as a formal PBI.
Conclusion
I’ve used this template with different teams with good results. Even though teams tell me they do still prefer me to facilitate the event, they also indicate that it offers them sufficient structure to feel comfortable doing the Sprint Planning without me. The truth is that I find myself with little to do once teams become comfortable with the template.
Try it out if you like and please let me know what you think so I can keep improving it!