How-to: Scrum Sprint Planning Part II / Topic Two
A practical approach to engaging the team in sprint planning
Twin Post!
This post is the second part of a Twin Post.
I started writing this post about Sprint Planning Topic 2, but noticed that when I also included some explanation about what is Topic 1 vs Topic 2, it became a bit long & unfocused . So I decided to split it into two separate posts. This post can be read stand-alone, but if you feel/notice that you need some more background about what the sprint planning topics are, or what I (the author) feel are the practical implications of the two different topics, then I urge you to first read the first post.
Who this post is for
Facilitators/Scrummasters or Scrum team members who are looking for inspiration on how to engage the team more fully in the detailed planning of the upcoming sprint.
Intro
I find Sprint Planning Topic Two to be a frequently neglected topic in many Agile teams. I go into details about this in my previous post ‘Sprint Planning: Two Topics!’.
In this post, I describe a format that can be used to get a higher degree of engagement from the team whilst elaborates on the ‘how’ of the sprint and giving an answer to ‘who will do which tasks to achieve the (sprint-)goal’.
In short, the focus of this post is to describe a way in which to engage the team more fully in answering the question ‘How will the chosen work get done?’.
Let’s get started.
A practical approach for Sprint planning Part II
Short format summary
This workshop-format assumes a separation between the topic I & topic II meeting. Planning Part I has already been concluded and a product backlog slice has been identified. This slice is taken as input for this Part II exercise together with any remaining work still left from previous sprint (we all know it’s there, we all know it shouldn’t :) ).
All these stories & tasks are visualized on a (virtual or physical) copy of the scrum-board. At which time a ‘sprint-simulation’ is started in which the team-members start out with an overview of the time they will be able to work on the upcoming sprint (the simulation-time). They (individually or in groups) pick stories they want to work on, discussing them with whomever is required or useful and putting them in the ‘done’ column when that story is clear (enough) and the tasks needed to complete it are identified & estimated.
During the exercise everyone records how much (simulation-)time they each still have available (keeping track of the time reserved for stories already ‘processed’). As long as there is simulated time available, they pick the next story, and the next, … until all stories have been processed, every-one runs out of simulation-time or the workshop timebox ends…
Getting started/preparations
Before running the simulation, some things need to be in place. They should be set-up before starting the excercise:
- A meeting room large enough for the number of participants to be able to sit together in smaller groups without disturbing each other too much (but not so large as to allow for groups to completely separate themselves).
- The product backlog slice for the upcoming sprint; the goal & backlog items to complete in the upcoming sprint have been identified.
- The backlog slice, together with the left-over of the previous sprint (if any) are visualised on a (virtual or physical) copy of the scrum board:
- Some simulation-time-keeping tool is provided to make it easier for the team members to track ‘time usage’ during the simulation. In my workshop I used a sprint agenda with every day separated into four 2-hour timeslots:
At the start of the workshop
- Explain the exercise: we are going to do a quick ‘sprint simulation’ in which we will translate the stories into time-estimated tasks and track our (virtual) time consumption (the itme we think we will need to complete them.)
- Give everyone a copy of the ‘sprint agenda’
- Ask to already cross out a large portion of the time in the Agenda to allow for interrupts & some slack (for instance, remove/mark 2 hours each day).
- Also ask everyone to scratch days in which they are unavailable for sprint work (because of meetings, vacation or otherwise)
- Time now still remaining is what actually can be used to get sprint work done (at this point, people are generally confronted with how little time that really is)
- Start the sprint simulation!
Running the simulation
During the exercise, people ‘simulate’ what they would do during the actual sprint. For instance, they pick up a task from the ‘code review’ column, estimate what time they would need to review this item, account for that in their ‘sprint agenda’ and move the ticket to the next column.
If a new story is picked up from the ‘todo’-column to the ‘doing’ column, processing that item will probably mean pulling the people together who are necessary for completing it, discussing what tasks are needed for the story completion and how long each task would probably take. These tasks are then documented & accounted for in the appropriate agenda’s, and if they all fit, the story is ‘planned’ and the story and newly created tasks can be moved to the ‘done’ column.
I generally ask the team to break down the stories into tasks with a maximum estimate of two days, preferably smaller. Larger tasks tend to be too abstract & hinder transparency in sprint progress, but sometimes exceptions can be made.
It may also become apparent that some (expert/specialist) members have a full schedule & can no longer support extra work whilst others are still mostly idle. Handle this as you would in the sprint; challenge the team to come up with a creative solution & rebalance the workload or (if that doesn’t work out) involve the PO to renegotiate the sprint scope. It’s not ideal, but it’s still preferable to learn about these problems before the sprint starts than while executing the actual sprint!
Finishing the workshop
The exercise ends when:
- Everyone’s (simulation) time is gone (agenda is full) and there are still stories remaining. In that case; let’s stop fooling ourselves. The proposed backlog slice does not seem to be realistic. Let’s talk to the PO to reduce scope for this sprint to maintain sustainable pace.
- The work is all planned, some team members still have some time available. Great, ready to go & some time in reserve for fixing or preventing technical debt!
- The timebox runs out. Ok, we start with what we have & adjust planning during the course of the sprint. It may be a point to consider raising in the retrospective as this may be indicative of some deeper root cause/team dysfunction…
Optionally the team can finish with a round-up ; inviting everyone to give a short overview of what their sprint is going to look like.
My experience
When we tried to do the Topic One & Topic Two in one go/meeting with everyone looking at the backlog & estimating/discussing story per story together, the meeting tended to drag on forever and was never concluded within the planning-timebox.
Furthermore, with a team size larger than 5 - it is inevitable that some stories have people who are very interested/involved and others who ‘check out mentally’ and are just waiting for the discussion about the current story to end (hopefully to be more involved with the next one). Resulting in meetings that feel very ‘draining’.
Splitting up the meeting really improved the team-engagement. Part I still consists of everyone shortly reviewing all the stories proposed for the next sprint, but the discussions are kept short & focused on ‘the problem to be solved’ and less on the ‘how’ & ‘how long’ of the execution, as that will be tackeld in the next part.
From the beginning, I was amazed by how fast this Part II format was. By parallelizing the discussions and letting everyone self-organize to have the needed discussions per story/task, Part II for a two week sprint was conducted in under the 1 hour mark. I must admit this was with a well-formed, experienced team, so I guess results may vary.
Importantly I feel this exercise provided a much better ‘reality check’ regarding the feasibility of the sprint. An added benefit experienced by the participants was that they felt they had achieved better alignment with regards to stories and tasks that need more co-operation.
Afterthought
Do Topic One and Two really require separate meetings? The scrum guide clearly describes them as separate topics to be discussed during the planning event. But if addressing both topics (at the same time) in the same meeting works for you, great! Go for it, I, however, have found that in some (most?) situations it does pay to at least explicitly acknowledge these two different topics as being different and to approach them in a different way. Formally splitting your planning meeting into two parts is a way to accomplish this.
I have noticed in the past that there are some widespread misconceptions regarding ‘Agile’ & ‘Planning’. One of the more obvious ones being that there is no Planning in Agile. That is nonsense. There is more frequent (and in many cases even ‘more’) planning going on in a healthy Agile environment. Involving the whole team in a more detailed planning for the upcoming sprint is an important aspect.
Something else some people seem to believe is that ‘estimating in hours is not Agile’. Although I agree that trying to estimate a whole product backlog (or even large parts of it) in actual time is an anti-pattern, Agile & Scrum themselves do not even prohibit that. It is up to the team to evaluate what estimation method/metric is best suited for each step in the process.
In practice I advocate at least two ‘levels’. Story points/velocity (or equivalent) on the backlog & actual time estimates for the sprint backlog tasks. I do warn however that just translating one into the other (story point to hours) IS an anti-pattern. They measure different levels of detail and as such cannot simply substitute each other by ways of a calculation.
Finally, another question that surprised me was: ‘isn’t this micromanagement’? It surprised me because I hate micromanagement with a vengeance, and thinking that I would be advocating such a practice does not sit well with me. But no, I do not consider this to be micromanagement at all. The team is in full control, they decide what to do and estimate how long they are going to go about it. Micromanagement would be if someone else starts deciding these things for them, or maybe even if the ‘plan’ resulting from this excercise would be used as a set of individual ‘promises’/fixed targets towards management. To do that would again be an anti-pattern and would be to miss the point completely.
A shared planning exercise such as described above is meant to be a way to allow the team to self-organize and adapt to the upcoming sprint & to have a clearer view on what each member thinks he can contribute in the upcoming sprint. The resulting plan is a starting point for further collaboration & adaptation during the sprint, not an end-point in itself.
To quote Eisenhower: ‘In preparing for battle I have always found that plans are useless, but planning is indispensable.’.
Or as put more plainly by the great philosopher Mike Tyson: ‘everyone has a plan until they get punched in the face!’.
