Perfect Planning

Best Practices for Successful Sprint Planning

6 August 2007

Guy Beaver
Critical Point Group

A successful sprint starts with the planning session. Taking the time to plan allows the team to review the work about to be undertaken, estimate the effort required to complete that work, and then commit to a prioritized list of stories and tasks that are within the team’s calculated capacity. This light set of procedures is well documented in Scrum and Agile literature [1],[2], but included here are some observable traits and best practices that have been found in well-formed, hyper-productive agile teams.

The purpose of the agile planning session is to present a collection of user stories to the team and allow them to be estimated. This is where team effort gets aligned with business direction, and is the essence of the agile phrase, “let the product lead.” At the end of the session, the team should feel committed to completing the work required to implement the agreed-upon list of user stories during the next sprint. An information radiator [3] should be loaded and prioritized with the sprint backlog of stories, and the team ready to begin the next day with a Daily Scrum.

A well-formed agile team has a product owner who is prepared for the planning session and is ready to present sprint goals and a prioritized list of stories for estimation by the team. This prioritization has a rhythm all its own. The product owner should review the product backlog frequently so that stories are staged and ready-to-go for planning sessions based on the latest business priorities. A best practice that helps make this happen is to visibly display the product backlog close the product manager’s office, so that he/she can has a constant reminder of the upcoming prioritization [4].

A well-formed agile team has a product owner who can clearly state the Vision (why the agile team exists) and can formulate clearly the goals for each Sprint [4]. This clearly stated vision and sprint goals should be used to begin the sprint planning session, so that guiding principles can be applied to each story considered for estimating. New stories are typically unfolded as the team asks questions of the product manager during the planning session.

Determining the team’s capacity is critical to a successful planning session and should be the first activity in the planning meeting. Two best practices for determining team capacity are:

  1. The total capacity of the team should be based on the following equation:

    # of team members × # of days in the iteration × (no more than) six hours.

  2. Start the planning session by establishing who has vacation time planned for the upcoming sprint and capturing that information in a vacation story. The vacation story has tasks for each team member’s time away, which accounts for some of the team’s capacity when stories are being committed. As the sprint progresses and the vacation days are hit, the burndown chart reflects these time-away tasks as being completed along with any other tasks. This prevents the burn-down from falsely indicating a problem.
    For example, suppose a five-member, well-formed agile team is planning a ten-day sprint. The capacity of the team is quickly established to be

    5 members × 10 days × 6 hours per day = 300 hours capacity.

    The ideal daily burndown is, therefore, thirty hours (300 hours of capacity ÷ 10 day sprint).

Since new agile teams typically have questions about how to handle time away (vacation, training, etc.), the following example helps illuminate best practice 2, mentioned above. A well-formed agile team is extremely tolerant of team members’ vacation and other time-away needs, as paired programming and role-sharing prevent silos of code territories to build up. When a team member is away, the well-formed agile team can easily adjust and continue creating business value. Suppose four team members are attending all-day training during the first day of the sprint. The team accounts for this by creating a time-away story that has four tasks, each with a six-hour estimate. These tasks get completed on the first day, so the burndown chart correctly shows the time burndown.

Notice that sprint capacity is calculated under the assumption that each team member has no more than six hours to commit per day. This buffer prevents the team from being over-committed, and is a responsible approach for accounting for distractions. This helps enforce the lean software development principle “limit work to capacity,” ensuring that a hyper-productive state is sustainable.

Planning is also the time for the agile leader to ensure that the agile team will create business value during the upcoming sprint. Effective agile leaders create an environment where each day is seen as an opportunity to close stories, and where daily progress is visible and is reinforced by a satisfied product owner.

The Perfect Planning session can be summarized in the agenda below. Try variations of it to plan your next sprint:

9:00–9:15  Daily Scrum (last scrum of ending sprint–discuss any unclosed stories and agreement on how to handle)
9:15–10:00  Demo of stories delivered over the course of last sprint
10:00–10:15  Break
10:15–11:15  Sprint Retrospective (what worked well, what can work better)
11:15–12:15  Lunch (Ideally catered)
12:15–1:00  Determine upcoming time-away and establish Team Capacity for the planned sprint
1:00–2:00  Visioning (product owner presents: Review OBT, discover Sprint Goals, discover Roles. Product owner presents each story in priority order)
2:00–4:00  Team reviews stories, creates estimated tasks for each
4:00–5:00  Team commits to chunk of stories to product owner, ready to start Daily Scrum tomorrow

A purely lean view considers planning and estimating a batch of stories as waste. Dave Anderson and Rick Garber (both of Corbis) gave a great presentation at the Lean Product Development Summit [5] where they demonstrated a pure Kanban implementation for software development that had no planning or estimating. Stories were instead pulled in to the iteration on a space available basis based on the current capacity. This approach has the potential to raise productivity.

It’s hard for me to imagine doing away with the planning session altogether. In my experience, the pause between sprints allows teams to celebrate and catch its collective breath while the retrospective provides feedback required for convergence of the complex adaptive system. However, it would be interesting to take a well-formed Agile team, and migrate it to pure Kanban to see what productivity gains could be realized.

For new agile implementations, though, the light rules of Scrum with agile/lean principles provide a proven transition to lean software development. The beauty of lean and agile principles is that they dictate that the best implementation is one that can be inspected and adapted. The Corbis implementation of this Kanban approach reinforces the application of situational agility, and I’m grateful for Dave Anderson and Rick Garber for illuminating this so well in their presentation.

References

1. Agile Project Management with Scrum, Ken Schwaber
2. Agile Estimating and Planning & User Stories Applied, both by Mike Cohn
3. see "Information Radiator," by Alistair Cockburn
4. see "Eye on the Prize: Best Practices for Aligning Agile Efforts with Business Goals," by Guy Beaver
5. see "A Kanban System for Sustaining Engineering on Software Systems," by Dave Anderson & Rick Garber

 


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Andy Murthar, CSM, 8/7/2007 7:29:43 AM
Geoffrey F. Fisher: When you aim for perfection, you discover it's a moving target.

Thus agile!

Mike Cohn, CST,CSP,CSM,CSPO, 8/8/2007 4:45:50 PM
Guy--Nice article. It should be pointed out, though, that the Kanban approach of Anderson and Garber was used for sustaining engineering (aka "maintenance") efforts. I've worked with many teams who plan sprints in the typical agile manner but also have their product owner provide a consistent flow of bugs into the sprint. For example, teams using a task board will dedicate one row to bugs and ask the PO to always keep one or two bugs in that row. The team commits during sprint planning to finishing some set of stories (product backlog items) plus as many bugs as they can. Sometimes at 4pm a programmer doesn't want to start anything big but does have the time / brain power to knock out a bug or two. This works well.

I don't think, however, that a kanban-style "let's just pull them in one at a time" approach works for software engineering that is of a more new feature / new development mode. Considering one feature at a time leads to inefficiencies because of not considering even the immediate future in our designs. I coach teams to think of the half-day sprint planning meeting as being not just a planning meeting but also a product design and technical design meeting. And it is. I wouldn't want to lose that based on some false efficiency belief from a manufacturing environment where there is less uncertainty about what we're building than there is on a software development project. Additionally, there is something important in the team selecting a set of backlog items and saying "we commit to this." I believe that teams that do this will get more done over time than teams who just grab things one at a time.
Regards,
Mike
Andy Murthar, CSM, 8/9/2007 4:35:25 AM
Mike: I agree. the 'we commit to this' is often underestimated in it's importance. We have been very clear with the product owners with regards to prioritisation and the difference between bugs and backlog. We operate a rotating support enviroment in which prioritised bugs are managed. This is built into the sprint time capacity.I am from an engineering background and researched the possibility of kanban methods before coming across agile practices. The self management ethos allows the team to take responsibility for 'bugs' and over time develop methods to avoid them more and more because developers don't like working on bugs.
Andrea Tomasini, CST,CSC,CSP,CSM,CSPO,REP, 4/1/2009 12:41:46 PM
Hi all, I agree with Mike too, we also developed a the idea to create a Contingent to "timebox" the bug fixing during a Sprint and thus avoid that they eat out too much time from the team capacity. The Contingent may be negotiated with the Product Owner at the Sprint Planning Meeting, depending also on the Sprint in which the team is going to jump in, in particular if it is the first after a new Product Release, there is an higher probability that bugs will be found.

The idea of the Contingent is to set a "timebox" for the Team to measure and preserve their commitment, when there is a new Bug coming up from the "production" system, every team member can pick it to fix it, and books the hours spent on the Contingent. When the Contingent is full, the Team can raise the hand and call the Product Owner to discuss if it is more important to focus on the Bugs or continue with the Sprint Commitment. The Product Owner - being in charge for the value prioritization - can decide to renegotiate the commitment, or postpone the Bugs till the next sprint.

By experience, depending on the "quality" of the product, an average team may allocate 15%... 5% of the capacity to fix bugs. In all the Projects we ran so far we found this to be a fair deal, and to enable Transparency effectively :-)

Best
ANdreaT
Mike Collins, CSM, 8/25/2009 9:26:52 AM
I'm a little confused about the statement that you can use a Kanban approach with no estimating. The article goes on to say that stories were pulled in to an iteration based on the current capacity. How do you know what the current capacity is if you aren't doing any estimation?
Jonathan Tracy, CSM,CSPO, 4/24/2013 1:42:53 PM
Reference Item Number 3 has changed to a new location.

You can find it here:
http://alistair.cockburn.us/Information+radiator
Nigel Farmer, CSM,CSPO, 7/25/2013 11:01:04 AM
Initially I liked the idea of adding a vacation story with tasks for each person going on vacation. I can see how this prevents the burn-down from falsely indicating a problem, however I would question if it really is a problem and whom it is a problem for. The burndown chart should be a reporting tool for the team to tell if they are on progress for the sprint and unless the team is too big or the sprint is too long, vacations should be manageable without having to add stories for them - you just have to calculate capacity per person and sum. My concern is that once you start putting in stories and tasks for vacations, there may later be a push to start putting stories in the for sickness etc especially if management are looking at the burndown chart. In my team we dont want to to use our tool to be a general purpose time tracking system - we already have 2 systems we have to use for that purpose and its already hard enough to get people to log spent/remaining time on daily basis without having to put vacations,sickness etc in as well, which I think we reduce the frequency of time entry and therefore the accuracy of the burndown chart.
Nigel Farmer, CSM,CSPO, 7/25/2013 11:51:21 AM
Initially I liked the idea of adding a vacation story with tasks for each person going on vacation. I can see how this prevents the burn-down from falsely indicating a problem, however I would question if it really is a problem and whom it is a problem for. The burndown chart should be a reporting tool for the team to tell if they are on progress for the sprint and unless the team is too big or the sprint is too long, vacations should be manageable without having to add stories for them - you just have to calculate capacity per person and sum. My concern is that once you start putting in stories and tasks for vacations, there may later be a push to start putting stories in the for sickness etc especially if management are looking at the burndown chart. In my team we dont want to to use our tool to be a general purpose time tracking system - we already have 2 systems we have to use for that purpose and its already hard enough to get people to log spent/remaining time on daily basis without having to put vacations,sickness etc in as well, which I think we reduce the frequency of time entry and therefore the accuracy of the burndown chart.

You must Login or Signup to comment.