By Guy Beave
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:
- 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.
- 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. "Information Radiator," by Alistair Cockburn
4. "Eye on the Prize: Best Practices for Aligning Agile Efforts with Business Goals," by Guy Beaver
5. "A Kanban System for Sustaining Engineering on Software Systems," by Dave Anderson & Rick Garber
