Agile Estimating and Planning
Agile projects rely on agile estimating and planning processes which answer the question: “What should we build and by when?” Answering this question requires first estimating (“how large is it?”) and scheduling (“when will it be done?”, “what can we deliver by then?).
Agile Estimating and Planning by Mike Cohn
Agile Estimating and Planning covers planning challenges and goals, estimation, prioritizing features and backlogs, scheduling, monitoring, and communication. Mike Cohn presents a comprehensive handbook for agile estimating and planning that includes the rationale for the agile approach along with a point-by-point explanation of why traditional planning methods don’t work.
Agile Planning
…planning is difficult. Teams often respond to this by going to one of two extremes: They either do no planning at all, or they put so much effort into their plans that they become convinced that the plans must be right.
Plans and schedules are required for a number of business imperatives: industry events, customer delivery dates, marketing campaigns, budget and resource availability, and downstream activities such as training. Although these pragmatic considerations drive the need for planning, Cohn says planning is primarily “a quest for value.” A planning team addresses “what should we build?” by considering features, resources, and schedules in an iterative and incremental manner. A good planning process supports finding the right combination of these three variables by reducing risk, reducing uncertainty, supporting better decision making, establishing trust, and conveying information. Cohn notes that the biggest risk on a project is not missing the schedule or overspending the budget, it is building the wrong product. Trust, another important quality of successful projects and teams, is built in agile projects through reliable estimates and frequent delivery.
Agile planning welcomes changes
A good plan as one that stakeholders find sufficiently reliable that the they can use it as a basis for making decisions.
Agile planning welcomes change based on learning and new information. Balancing the time and effort required for planning with the foreknowledge that the plan will change is a key to successful agile planning. “This means we need plans that are easily changed,” writes Cohn. It’s important to note that agile planning does not automatically lead to date changes. In agile planning, dates may change, features may change, or quality may change–all depending on decisions made in the planning process. To support these principles, agile planning is spread through the entire duration of the project rather than front-loaded at the beginning.
Features are the unit of customer value. Planning should, therefore, be at the level of features, not activities.
Traditional planning focuses on activities rather than features which shifts the focus away from customer value and introduces a host of issues. Dependencies between activities create cascading schedule delays and individual activities rarely finish early. Moreover, features are not developed in order of priority and uncertainty is masked by the presence of an elaborate written plan.
The Agile way
Projects should be viewed as rapidly and reliably generating a flow of useful new capabilities and new knowledge, rather than just a series of steps. Projects generate two types of new knowledge: knowledge about the product and knowledge about the project.
The Agile Manifesto written in February 2001 has four key principles that define the agile approach:
- Individuals and interactions over processes and tools
- Working softwre over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Taken together, these value statements guide the way agile teams work:
- Work as one team
- Work in short iterations
- Deliver something each iteration
- Focus on business priorities
- Inspect and adapt
Agile teams have specific roles including product owner (responsible for product vision and prioritizing features), customer (person paying for the project or purchasing the software), user, developer, and manager. Agile teams work in short iterations of pre-defined duration and deliver working software (including features prioritized according to business value) at the end of each iteration. Three levels of planning ar used: release planning, iteration planning, and daily planning. Release planning focuses on the Product Owner’s conditions of satisfaction which are comprised of user stories, budget and schedule. Iteration conditions of satisfaction consist of user stories and acceptance tests.
Agile estimation
In agile projects, the desired features are written as user stories which are then estimated for size. Estimates are typically in the form of “story points” that provide relative size. Story point completion is tracked for each iteration to determine velocity (story points per iteration). Once velocity is calculated, a duration can be derived (based on best case, worst case, and average case velocity). From there, a schedule can be constructed.
Prioritizing features
Cohn suggest four factors to take into consideration when prioritizing based on business value:
- Financial value of having the feature
- Cost of developing (and maintaining) the feature
- The amount and significance of learning and new knowledge created by developing the feature
- The amount of risk removed by developing the feature
When considering risk, Cohn uses a risk/value matrix and recommends delivering high-risk / high-value features first, followed by low-risk / high value, and finally low-risk / low-value. High-risk / Low-value features should be avoided.
Revenue can be broken down into new revenue, incremental revenue, retained revenue, and operational efficiencies.
Cohn uses the Kano model of customer satisfaction to give context for feature prioritization decisions. The Kano model has two axes: customer satisfaction (low to high) and feature presence (absent to fully implemented). Features which provide high satisfaction based on even a partial implementation are “exciters and delighters”. Features which do not provide a higher level of customer satisfaction even when fully implemented are “must-haves or mandatory”.
Agile release scheduling
Release planning and iteration planning form the core of scheduling activities in the agile approach. Iteration plans contain taks and are estimated in story points or ideal days; release plans contain user stories and are estimated in ideal hours. Iteration plans usually span multiple iterations and last three to six months. Essentially, an agile team will iterate until the conditions of satisfaction for the release can be met.
The agile scheduling process consists of these steps: 1) determine conditions of satisfaction; 2) estimate the user stories; 3) select an iteration length; 4) estimate velocity; 5) prioritize user stories; and 6) select stories and release date.
Using buffering to reduce risk
Cohn has an interesting chapter on buffering for uncertainty which addresses the inevitable unknowns in any project. He illustrates creating schedule buffers, feature buffers, and a combined buffer. In projects where time is of the essence, a schedule buffer can be implemented. For feature-driven projects, a feature buffer is used. A combined feature and schedule buffer can provide a range inside which a release or delivery can be made.
There’s a lot of detail in the book–it’s meant for a team to read and discuss together. He covers planning for multiple teams which is an important consideration for large projects. Also, Cohn explains how to monitor release and iteration plans and communicate status. There’s a case study at the end which tells the story of an agile team working on a hypothetical software product. If you buy in to the agile approach and want a book with which to start right away, this is a great pick. It covers all the bases and provides the conceptual framework along the way.
An organization’s ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage. —Jack Welch
