Most teams don’t finish everything they plan to finish every iteration. Management, or even Scrum Masters, tend to respond by asking teams to plan better during their sprint planning meetings.
This is often the wrong response.
Why Teams Can’t Plan Sprints Perfectly
Not everything is predictable. The team may be interrupted more, or less, during the sprint than they anticipated during the sprint planning meeting.
Similarly, a team cannot perfectly anticipate every task that will be needed. They may fail to identify some tasks that are necessary or they may identify tasks that turn out not to be needed.
For example, after I write the first draft of this blog post, I will send it to my editor and she’ll return it to me to review her edits. I estimate we’ll need one round of edits and revisions. But sometimes my first draft really sucks, and we need two (or more) rounds of edits and revisions.
I typically plan on one round of edits because that is normally enough. But that means I sometimes am missing tasks from my blog writing plan. However, if I planned for two rounds of edits for every blog post, I would sometimes have identified unnecessary tasks.
It seems I just can’t get it right.
The Problem with Thinking Harder
Neither can your team. No matter how often or stridently team members are told to “think of everything,” they can’t.
The good news: They don’t need to.
What to Do in Sprint Planning Meetings Instead
Instead of attempting the impossible and trying to identify and estimate every task that will be done in a sprint, the team should instead quickly identify only the main tasks.
Think about this way: Suppose you are planning your first trip to France. Paris will, of course, be one of your stops. But you also want to visit Nice, Cannes, Marseille, and others. How many days should you spend in Paris?
You don’t need to map out a complete hour-by-hour itinerary to decide how much time to spend in Paris. Making a rough list of the most important things you want to see or do in Paris would help you decide whether five or seven days is best, considering all else you want to do on your trip.
It’s the same for an agile team during its sprint planning meeting. Identifying the major tasks necessary to get done is sufficient for deciding how many and which product backlog items can be brought into the sprint.
Target Identifying About Two Thirds
In my experience, good agile teams can successfully do sprint planning by targeting about two-thirds of the tasks that will ultimately be completed during the sprint.
I want to be really clear about that: I’m not saying they plan about two-thirds of their available time. I said they identify about two-thirds of the tasks they’ll ultimately do. Those would be things like
- Code this (crucial) thing
- Test that (crucial) thing
- Update the design based on user feedback
- Meet with key stakeholders about some topic
- Add this field to the report
For example, if a team will ultimately complete 60 bits of work during an iteration, identifying 40 of them during the sprint planning is sufficient for a well-planned sprint.
Returning to our Parisian holiday, identifying 8 of the 12 things we’ll ultimately do in Paris would be enough.
It’s worth repeating that the items identified should be the main, bigger, and more easily identified activities. That means that identifying two-thirds of the tasks may represent 80–90 percent of a team’s available working time during a sprint.
How Many Tasks Should a Team Do in a Sprint?
Let’s turn the vague advice of identifying two-thirds of a team’s tasks into something more directly usable.
To do that, imagine how wonderful life would be if every day every team member said in the daily scrum, “Yesterday I did exactly this one thing and today I’ll do exactly that other one thing.”
Life would be wonderful if every day every team member finished exactly one task. For example, a six-person team running a ten-day (two-week) iteration would complete 60 tasks (6x10).
That means in this example, team members would target identifying around 40 of their eventual 60 tasks. The remaining tasks will be identified naturally during the sprint.
Don’t Plan Every Detail During Sprint Planning Meetings
If you follow this advice, team members probably will not plan as many tasks as they are accustomed to doing during the sprint planning meeting. So the sprint may seem less full at first. But the reality is, it won’t be.
Returning to our holiday, identifying only the main things you’ll do in Paris doesn’t mean you’ll be sitting on the Champs-Élysées twiddling your thumbs with nothing to do for the last two days of your trip.
Rather, you’ve identified the main activities of your holiday, knowing that once in Paris you’ll find plenty of additional things to joyfully fill any unplanned time.
The same is true for a team that identifies only the main activities of a sprint. Unplanned time will be filled with the smaller tasks that are best identified during the sprint.
The Advantage
The advantage of working this way is that sprint planning meetings can be done more quickly with less frustration and no loss of accuracy in planning the sprint.
I wrote a book on estimating and planning. Trust me: if anyone in the world wants to be in a planning meeting, it’s probably me.
Yet far more I find myself coaching a team to spend less time in its sprint planning meetings rather than more.
All too often, team members become obsessed with trying to identify every last thing they’ll do in a sprint. You don’t need to know you’ll sip coffee at the Café de Flore on Thursday from 11:00 – 11:25 to plan your trip to Paris.
What Do You Do?
How thoroughly does your team attempt to plan its sprints? Would you say you spend too much time, too little time, or just the right amount of time in your iteration planning meetings? Please share your thoughts in the Comments section below.
