Agile development practices, when performed correctly, are lightweight and inexpensive, avoid wasted cycles, and ensure that just the right features are built. In this article you will find successful ways to make and meet iteration commitments, techniques for leading a team or teams through an effective iteration planning meeting, and tips on how to establish priorities, size your stories, and plan your iterations better.
I am very fortunate as an Agile Coach with Rally to constantly be around teams who want to become leaner and more agile. Those who do the work, plan the work is a principle I hold dear, yet it is a struggle for many to create such a self-organizing, self-managing team. I was reminded of this in July of this year (2009). I was invited to give a webinar on Agile Planning. I expected perhaps a few dozen attendees yet 1400 people registered and 3 months later I was still answering questions. The content of that webinar is the inspiration for this article and my target audience is the team that is new to agile and lean concepts.
The Mechanics of an Agile Iteration
Most of today's agile teams use iterations to maintain a constant tempo. The iteration begins when the team selects the product features to be delivered at the end of the iteration, identifies the tasks needed to complete those features and commits to the iteration. During the iteration the delivery team meets each day to plan that day. At the end of the iteration the team produces a potentially shippable product increment.
The Product Backlog is the list of desired product features. It is expressed so that each item is value focused. It is owned and prioritized by the Product Owner. The Product Owner represents (or is) the user/client. They act as one voice even if they are not one person (Roth 2009).
Most agile organizations use User Stories to describe their Product Backlog items. Stories should be described briefly with detail deferred until closer to the time that commitments need to be made. Deferring commitment is a lean principle that helps us avoid the waste of detailing stories that may never be implemented and also allows us to make decisions with the maximum amount of information possible.
The list of tasks to be completed in the iteration is the Iteration Backlog. These tasks are performed by a Delivery Team consisting of 5-9 individuals who commit to the work they select for iteration.
The ScrumMaster facilitates the team and the team's relationships with outside interests. They enforce agile values and practices and don't make decisions for the team or time and budget commitments on the team's behalf.
Grooming the Backlog
Before a team plans the iteration the Product Backlog needs to be groomed to ensure that the backlog items are ready to be worked on. This is a collaborative effort involving the Product Owner and the Delivery Team. The Product Owner determines what the priorities are and ensures that everyone understands criteria for acceptance of the backlog items. The team needs to estimate the size of the backlog items and those that are high priority and too large to be completed in an iteration need to be broken down.
User Stories by definition consist of a brief description. This is not enough information to estimate the story, implement the story and to verify whether the implementation meets expectations. Therefore before the team starts planning we need to ensure we have clear and verifiable acceptance criteria for each story. There are various forms for documenting acceptance criteria. A simple form is just a bulleted list. Identifying acceptance criteria can often reveal new stories that may affect priorities for the upcoming iteration.
Prioritizing the Backlog
The Product Owner prioritizes the Product Backlog. A stack ranking is preferred where no two items have the same priority. This can be a challenge where there are multiple Product Owners but a simple technique such as dot-voting (Tabaka 2006) can help. Where the Product Owner is representing a large constituency more thorough techniques such as Kano Analysis and Relative Weighting can be employed (Cohn 2006). Often size estimates affect how a Product Owner feels about priorities so it is expected that priorities will be revisited after estimation.