Agile Estimating and Planning

by Mike Cohn

Giving a product or project manager sage-like qualities to be able to foresee what others, who are experts in their own work, can really deliver is business suicide.

Planning increases the likelihood of project success by providing insights into the project’s risks.

Throughout a project, the team is generating new capabilities in the product. They are also generating new knowledge—about the product, the technologies in use, and themselves as a team. It is critical that this new knowledge be acknowledged and factored into an iterative planning process that is designed to help a team refine their vision of the product.

The most critical risk facing most projects is the risk of developing the wrong product. Yet this risk is entirely ignored on most projects.

estimates help us make sure we are working on the most valuable projects possible.

Frequent reliable delivery of promised features builds trust between the developers of a product and the customers of that product. Reliable estimates enable reliable delivery. A customer needs estimates to make important prioritization and tradeoff decisions. Estimates also help a customer decide how much of a feature to develop.

Reliable estimates benefit developers by allowing them to work at a sustainable pace. This leads to higher-quality code and fewer bugs. These, in turn, lead back to more reliable estimates because less time is spent on highly unpredictable work such as bug fixing.

A plan conveys expectations and describes one possibility of what may come to pass over the course of a project. A plan does not guarantee an exact set of features on an exact date at a specified cost. A plan does, however, communicate and establish a set of baseline expectations.

Agile planning balances the effort and investment in planning with the knowledge that we will revise the plan through the course of the project.

Features are the unit of customer value. Planning should, therefore, be at the level of features, not activities.

It is human nature when ahead of that schedule to fill the extra time with other work that we, but perhaps not others, value.

Logically, it makes sense that multitasking helps when you have two things to work on; if you become blocked on one, you can switch to the other.

it encourages focusing on achieving a high level of utilization of all individuals on the project rather than on maintaining sufficient slack to cope with the inherent variability in typical project tasks. Loading everyone to 100% of capacity has the same effect as loading a highway to 100% of capacity: No one can make any progress.

traditional planning fails to lead consistently to high-value products is because the work described by the plan is not prioritized by its value to the users and customer. Many traditional plans are created with the assumption that all identified activities will be completed. This means that work is typically prioritized and sequenced for the convenience of the development team.

A problem with traditional planning can arise if the project team or its stakeholders equate estimating with committing.

an estimate is a probability, and a commitment cannot be made to a probability. Commitments are made to dates.

specific iteration length chosen by a team is that during the iteration they transform one or more imprecise requirements statements into coded, tested, and potentially shippable software.

A good release plan is updated throughout the project (usually at the start of each iteration) so that it always reflects the current expectations about what will be included in the release.

Agile teams use three levels of planning: release planning, iteration planning, and daily planning. The release plan looks ahead for the duration of the release—typically, three to six months. An iteration plan looks ahead only the duration of one iteration—typically, two to four weeks. A daily plan is the result of team member commitments made to each other in a daily stand-up meeting.

Agile teams separate estimates of size from estimates of duration.

Story points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work.

The number of story points associated with a story represents the overall size of the story. There is no set formula for defining the size of a story. Rather, a story-point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on.

On an agile project it is not uncommon to begin an iteration with incompletely specified requirements, the details of which will be discovered during the iteration. However, we need to associate an estimate with each story, even those that are incompletely defined.

Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration.

A key tenet of agile estimating and planning is that we estimate size but derive duration.

The beauty of a points-based approach to estimating is that planning errors are self-correcting because of the application of velocity.

slower. The beauty of this is that estimating in story points completely separates the estimation of effort from the estimation of duration.

After years of this, most football fans know that when a football game is scheduled to end at 4:00, that is only an estimate. No one is surprised when the game goes till 4:15 (an overrun of 8%). They may be frustrated or annoyed but not surprised. Why, then, are we surprised when a software project estimated at twelve months takes thirteen (an equivalent 8% overrun)?

No matter how much effort you put into an estimate, an estimate is still an estimate. No amount of additional effort will make an estimate perfect.

Estimates are not created by a single individual on the team. Agile teams do not rely on a single expert to estimate.

Each of these numbers should be thought of as a bucket into which items of the appropriate size are poured.

For features that we’re not sure we want (a preliminary cost estimate is desired before too much investment is put into them) or for features that may not happen in the near future, it is often desirable to write one much larger user story. A large user story is sometimes called an epic.

Additionally, a set of related user stories may be combined (usually by a paper clip if working with note cards) and treated as a single entity for either estimating or release planning. Such a set of user stories is referred to as a theme.

it’s important that they realize that estimates of themes and epics will be more uncertain than estimates of the more specific, smaller user stories.

User stories that will be worked on in the near future (the next few iterations) need to be small enough that they can be completed in a single iteration. These items should be estimated within one order of magnitude.

“This story is a little bigger than that story.” When estimating by analogy, the estimator compares the story being estimated with one or more other stories. If the story is twice the size, it is given an estimate twice as large. There is evidence that we are better at estimating relative size than we are at estimating absolute size

When estimating this way, you do not compare all stories against a single baseline or universal reference. Instead, you want to estimate each new story against an assortment of those that have already been estimated. This is referred to as triangulation. To triangulate, compare the story being estimated against a couple of other stories. To decide if a story should be estimated at five story points, see if it seems a little bigger than a story you estimated at three and a little smaller than a story you estimated at eight.

The product owner participates in planning poker but does not estimate.

After all questions are answered, each estimator privately selects a card representing his or her estimate. Cards are not shown until each estimator has made a selection. At that time, all cards are simultaneously turned over and shown so that all participants can see each estimate. It is very likely at this point that the estimates will differ significantly. This is actually good news. If estimates differ, the high and low estimators explain their estimates.

If we keep in mind that story points and ideal time estimate size, it’s easier to see that we should re-estimate only when we believe a story’s relative size has changed.

At the end of an iteration, I do not recommend giving partial credit for partially finished user stories. My preference is for a team to count the entire estimate toward their velocity (if they completely finished and the feature has been accepted by the product owner) or for them to count nothing toward their story otherwise.

an estimate in ideal days will change as a developer’s proficiency changes. This does not happen with story points—the size is what it is and doesn’t change. That is a desirable attribute of any measure of size.

it is generally difficult to estimate the value of small units of functionality, such as a single user story. To get around this, individual user stories or features are aggregated into themes. Stories and themes are then prioritized relative to one another for the purpose of creating a release plan.

four factors that must be considered when prioritizing the development of new capabilities. 1. The financial value of having the features. 2. The cost of developing (and perhaps supporting) the new features. 3. The amount and significance of learning and new knowledge created by developing the features. 4. The amount of risk removed by developing the features.

On many projects, much of the the overall effort is spent in the pursuit of new knowledge. It is important that this effort be acknowledged and considered fundamental to the project.

Acquiring new knowledge is important because at the start of a project, we never know everything that we’ll need to know by the end of the project.

The high-value, high-risk features should be developed first. These features deliver the most value, and working on them eliminates significant risks. Next are the high-value, low-risk features. These features offer as much value as the first set, but they are less risky. Therefore, they can be done later in the schedule. Because of this, use the guideline to work first on high-value features, but use risk as a tie-breaker.

Be aware that a feature’s risk and value profile changes over time.

Separating product features into the previous three categories can provide a great deal of information about how to prioritize work for a new product release. The process of doing so was originated by Noriaki Kano, whose approach gives us a way to separate features into three categories: • Threshold, or must-have, features • Linear features • Exciters and delighters

Threshold features are those that must be present in the product for it to be successful. They are often referred to as must-have features.