I've been working on reading Agile Estimating and Planning by Mike Cohn, so I figured I would post my notes here as a follow up to my notes on Extreme Programming Explained. The book starts by introducing the purpose of planning, and why traditional methods of planning fail. Right from the beginning (even the title), it stresses that the estimating and planning process itself must be agile. Planning should reveal what should be done and when, and estimating should reveal how big a project really is.
The Purpose of Planning
- Planning is an attempt to answer "What should we build?" through consideration of features, resources, and schedules.
- Planning supports better decision-making, establishes trust, and helps set appropriate expectations.
- "The most critical risk facing most projects is the risk of developing the wrong product." - Planning can help reduce the risk of uncertainty and take the guess-work out of developing without a plan.
- "The knowledge and insight we gain from planning persists log after one plan is torn up and a revised one put in it's place." - We should be eager to change the plan; it means that we have either learned something or have come up with a better idea.
- Don't try to plan an entire project at the beginning. Agile planning should be spread evenly across the project's duration.
The reason I picked up this book was to read about release and iteration planning, so those are the parts I will highlight here. I have never personally be involved in a release planning meeting, and we talk a lot at Integrum about how we need to be better about release planning. We've also tested out a handful of iteration planning techniques, so I was really interested in what this book had to say.
Release Planning
Release planning produces a high-level plan that involves about 3-6 months worth of work. It helps the product owner and the team decide how long it will be before they have a releasable product. It sets expectations about the time-frame for a project - what will be done, and when? The author says, "without the concept of a release, teams move endlessly from one iteration to the next." I can attest, it is disheartening to developers to work and work without a release in sight. The steps of release planning are as follows:
- Determine criteria that will make the project a success or failure. (Based on the company's goals)
- Estimate the user stories.
- Choose the length of your iterations.
- Estimate velocity. (Planning Poker)
- Have the product owner prioritize the user stories according to what is most valuable to the success of the product.
- Select stories to be completed for the current release and set a date.
- Revisit the release plan after every iteration.
Iteration Planning
Iteration planning provides a short-term, detailed view of the work for one iteration within a project's release. It helps lead the team into a discussion about product design and set expectations for the customer about what features will be completed in the current iteration. The result of an iteration planning session should be a spreadsheet or index cards stating the stories, as well as tasks that go with each story. The book outlines two types of iteration planning; Velocity-driven and Commitment-driven.
Velocity-driven planning involves determining the target velocity based on an average of past iterations, then choosing the top prioritized stories that will fit within that velocity.
Commitment-driven planning involves choosing the top prioritized story from the backlog, writing tasks for that story, and then asking the team if they can commit to delivering that entire story in the current iteration. This process is repeated until the team can no longer add stories to the iteration.
The team at Integrum has tried both these methods of iteration planning. We recently switched back to velocity-driven planning, since the general feeling was that commitment-driven planning created too much overhead. Mike Cohn recommends commitment-driven planning because he feels it is more accurate than relying on story points and "yesterday's weather." What do you think?
Tips for Iteration Planning
- Don't allocate tasks to certain pairs/individuals during iteration planning. It takes away from the "all in it together" attitude.
- Organize stories and tasks so it is easy to tell what task goes with what story.
- Don't get too far into a discussion about design. All you need at the time of iteration planning is guesses about the work to be completed.
These are just the highlights I took from Agile Estimating and Planning by Mike Cohn. For more information, go read it yourself! Please comment with thoughts or experiences on release/iteration planning. Thanks!
