A successful sprint starts with the planning session. This is where the team reviews the work about to be undertaken, and after a few hours of questions and answers, estimates the work required to complete the user stories reviewed, and then as a team, commits 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.
A well-formed Agile team establishes an intangible sense of rhythm, and enjoys the transition time between iterations or sprints. This period provides closure for work completed, and anticipation of new work. Ideally, the Agile planning session should follow a demo and retrospective (all in the same day), to give the team a chance to celebrate, reflect and get better. Sprints should be consistent in length to help the Agile team develop this sense of pace. An experienced Agile Leader understands that shorter sprints (10 days is ideal) are much easier to plan & estimate. Longer sprints (> 10 days) tend to allow teams to decrease the sense of urgency during the first several days, and it is more difficult to contain and understand total scope than shorter sprints. In Complex Adaptive Systems [3], rapid feedback is critical to convergence.
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 the 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 [4] should be loaded and prioritized with the sprint backlog of stories, and the team ready to begin the next day with Daily Scrum for day 1.
A well-formed Agile team has a product owner who is prepared for the planning session, and ready to present sprint goals and a prioritized list of stories for estimation by the team. This prioritization has a rhythm all its own, as 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 the product manager’s office, so that he/she can has a constant reminder of the upcoming prioritization [5].
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 [5]. 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.
The Agile Leader calculates the sprint capacity by assuming each team member has no more than 6 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” to ensure that the hyper-productive state is sustainable.
The Agile Leader is focused on setting the Agile team up to be successful in creating business value during the sprint being planned. The Agile Leader creates an environment where each day is seen as an opportunity to close stories, and visibly see daily progress in the Agile-V [6], reinforced by a satisfied Product Manager. New Agile teams typically have questions of how to handle time away (vacation, training, etc). 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.
Determining the team’s capacity is critical to a successful planning session. This should be the first activity in the planning meeting. Two best practices for determining the team capacity are:
1) The total capacity of the team should be based on the number of team members times the number of days in the iteration times (no more than) 6 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 members’ time away, which account for some of the team’s capacity when stories are being committed. As the sprint progresses and the vacation days are hit, the burn-down chart reflects these time-away tasks being completed along with any other tasks. This prevents the burn-down from falsely indicating a problem.
For example, a 5-member well-formed Agile team is planning a 10-day sprint. The capacity of the team is quickly established to be 5 members X 10 days X 6 hours per day, which gives a capacity of 300 hours. The ideal daily burn-down becomes 30 hours. If 4 team members attended training during day 1 of the sprint, this can be easily accounted for by creating a time-away story that has 4 tasks, each with a 6 hour estimate. These tasks get completed on the first day, so the burn-down chart correctly shows the time burn-down.
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 the 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
12:15-1:00 Determine Vacation 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 of the Agile planning session sees 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 [7] where they demonstrated a pure Kanban implementation for software development that had no planning or estimating, and pulled stories in as capacity freed. This approach has the obvious potential of further raising productivity for standard Agile processes. For some situations, the pause between sprints allows teams to celebrate and catch its collective breath while the retrospect provides feedback required for convergence of the complex adaptive system. 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. I think for new Agile implementations, the light rules of Scrum with Agile/Lean principles provide a proven transition to Lean Software Development, however the beauty of the principles behind Lean and Agile dictate that the best implementation is one that can inspect and adapt. 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. Agile Management for Software Engineering (chapter 2), by David J. Anderson
4. see Information Radiator, Alistair Cockburn
5. see Eye on the Prize: Best practices for Aligning Agile efforts with business goals
6. see A Kanban System for Sustaining Engineering on Software Systems, by Dave Anderson & Rick Garber
Architecture is the context within which particular stories are implemented. In the context of scrum or agile we are considering architecture from the context of software development. The purpose of software architecture is not to define the place for the pieces as much as it is to separate the dependencies of the pieces. The purpose of architecture is not to build a framework within which all things can nicely fit. It is to define the relationships between the major concerns of the system so when they change or new requirements emerge the impact of the changes required are limited to local modifications. Limitation of concerns to local areas allow us to think of the system in a computerized fashion and treat things as independent encapsulate modules.
