This year’s SPCT day and SAFe Summit had me thinking about some of the variations of I’ve used for team-level activities over the last seventeen (!) years. One of the big things that has served me well is having a variety of different techniques for sprint planning that I use with teams, depending on where they are in the organization, what their goals are, and what’s needed for that team to be successful. In practice, I tend to default to goal-first planning, but I’ve used all of these techniques, and thought they’d be valuable to introduce here. As always, if you’d like to continue the conversation on LinkedIn, you can do so here.
Why have multiple approaches
If you’re looking at multiple approaches to sprint planning, the first question to ask is: “why?” which in this case is “why have multiple approaches?” The answer to this question is two-fold.
First, we need to acknowledge what the team is formally committing to. In a Scrum environment, whether part of an ART or standalone teams, what the team commits to is a sprint (aka iteration) goal. It’s not to the stories, to velocity, a set of tasks, or even a set of business outcomes. Rather, the team commits to achieving a sprint goal that they define as part of sprint planning.
Second, every team is different. The team’s charter will inform the priorities it holds and the trade-offs that it needs to make, and the nature of a team’s commitment will often shape how it commits to different things. For example, some teams have a response-driven mandate and have a responsibility to drop their planned work immediately if certain escalations or needs arrive to maintain an SLA. Other teams are very plan driven and have many teams relying on specific delivery dates to satisfy dependencies and maintain overall progress. These give rise to different commitment types, which lead to different ways of planning. The same team might even use different planning approaches in different sprints depending on what they need for that period.
Getting to a goal
So what does sprint planning really require? It requires identifying what that goal is. Then, the team needs to figure out how feasible that goal is, how they want to work together to achieve that goal, and what questions they really need to answer in order to achieve that goal. Only then can they make the commitment to work together to achieve that sprint goal. Throughout the sprint, they’re expected to adjust how they are working together to better achieve that goal when the opportunity or need arises.
Reiterating, the two important outcomes of sprint planning are 1) having a clear goal committed and 2) having a shared understanding of how the team will collaborate to achieve the goal.
Approaches to planning
I have five different approaches that I’ve used over time, organized from most detailed to least detailed:
- Traditional, full tasking
- Traditional, story-only
- Story-based saturation
- Goal-first
- Goal-only
The overall labels are quite useful to facilitate discussions between teams and leaders, and to help a team consider different approaches to its planning. The specific details vary within and across teams because there is lots of empty space between these, and a team might do “saturation, but with a touch of estimation and some tasks” which really blurs several of the approaches.
Traditional, full tasking
This is the approach many Scrum trainers over the years have taught. It’s the first way I learned to teach and do sprint planning, and it’s kind of that old traditional blend between agile planning and individual human “resource” based planning based on skill sets. This is where the product owner formally brings in a set of user stories that the team considers. The team works through the user stories and figures out how big each story is, often through planning poker. The team then decomposes each story into a set of tasks, where each task can then be pre-assigned to an individual and estimated in hours. That information is then used to compare across the team to make sure no individual or skill set is overloaded.
This approach is often perceived by teams as being slow and heavy, but if you have a set of functional specialists within a single scrum team, and they need to balance and ensure that no one of them is overloaded, and you’re kind of new at being a scrum team, this actually works pretty well. I do find that teams with more generalists rarely see the value here, and even deeply specialized teams can move out of this model fairly quickly.
Traditional, story-only
This approach is very similar to the heavyweight approach in its overall feel. The team estimates and plans stories in detail using historical velocity to understand what they can deliver. The main difference from the above is that a team doesn’t assign tasks in advance, and may not even write the tasks. They certainly don’t estimate tasks. Often, this still feels like sketching out the stories in terms of high-level tasks to understand what the stories require. As teams get more experienced they tend to become more flexible inside the team about who can do what, leading to multiple people that can pick up each individual task. They still write and estimate their stories, and coming out of planning they have a set of stories in priority order that they’re ready to do.
The team’s commitment, in both of these approaches, really feels like committing to the stories in the first two approaches, and often the sprint goal isn’t really much more than to finish the stories.
Story-based Saturation
This technique is where things start to feel different and perhaps a bit odd for many ScrumMasters. In this model, the team starts with a list of user stories, makes sure they’re well formed, and talks about each one from an approach perspective. The stories have great acceptance criteria and the team really knows what success looks like for each of those stories. But then, instead of going through the detailed estimation process and the deep dive, the team just starts at the most important work and asks “how are we going to work together to solve it?” and then “can we get it done?” Assuming the team generally thinks yes, then they move to the next most important story and repeat until the team isn’t confident in saying yes. The team might go through a couple more as a sort of stretch goal, but the sprint goal becomes a statement of intent around the stories the team had confidence they could complete.
This approach is faster and easier, and usually very comfortable for teams working in domains where they’re familiar and confident of the complexity (and good at spotting and naming the unknowns). The results are pretty good, and teams routinely overdeliver one or two stories… and that’s ok. It’s sufficient and predictable. If the organization expects a commitment that feels like a list of stories, this is my go-to approach for mature teams with a good engineering history and decent understanding of their domain.
Goal-first planning
For this approach the Product Owner doesn’t bring in a list of stories. Instead, the PO brings a clear goal and a set of things they’re trying to learn or accomplish at a high level. The team works together to shape it out, identify the most important actions to accomplish that goal, and form them into a list of directed activities that the team will pursue to achieve as much of the goal as possible. This list -might- look like stories, or it might not, and I’m not overly concerned so long as the team understands clearly the purpose of the work, the personas it supports, and what success looks like.
This approach messes with people and companies because they’re used to a list of stories, and this approach explicitly and only provides the sprint goal, not the list of stories. That list of work/actions is transparent, but it doesn’t show up how people are used to it. As a result, it requires a bit of trust, and a reminder that nowhere in Scrum does it state you plan in terms of stories… people just built a habit over 20 years of doing it that way. We need trust from the stakeholders on the ambiguity and trust from the team that they’re not going to be punished for misunderstandings around what that goal actually was. I find this one of the most powerful modes of operation for a team when it’s possible, but also one that’s hard to get going sometimes.
Goal only
The last approach is one that states a clear goal, but has very little planning of how to achieve it. It tends to apply in two general environments:
1 – Highly reactive environments where the work will emerge during the sprint. In this case, the sprint goal looks a lot like a service level agreement of the form “We’ll do up to 20 of this type of thing, and each will be handled within 2 days of arrival, assuming the arrival is fairly even throughout the sprint”
2 – Environments where the team is actively exploring a new space, and the goal is framed in terms of learning discovery. In this case, the sprint feels like working through a series of spikes, where each spike is based on the learning of the previous one.
I generally don’t love using this approach unless the team is very much in a ticket-based model where the work is randomly arriving. Essentially, this becomes a way to put a simple Scrum wrapper around what is otherwise a pure kanban flow. The exploratory case can be valid, but even then I’d like to have a list of likely experiments and what they’re trying to achieve to allow the team to understand each other better, even if those experiments are just bullet points and outcome statements that get thrown away after the first few experiments.
How to pick
This part’s easy: do what works, supports your stakeholders, and delivers results. Experiment!
In practice, you need to pick the one that works for you. Pick the one that delivers great results, supports your stakeholders’ needs, satisfies the team, and helps you get through planning with a great alignment among the team about what needs to be done. Don’t assume any one model will be successful long term and it might change for any given team over time.
Personally, my go to for most teams is either story-based saturation or goal first-planning. Those are the two that I find quick, easy, and generate the best alignment without feeling like you’re deep diving and playing story Tetris.
