Agile Estimating and Planning (Robert C. Martin Series)

by Mike Cohn

Individuals add padding to an estimate if they expect to be beaten up if they are wrong. A schedule buffer is different: A schedule buffer is a necessary margin of safety added to the sum of estimates from which local safety has been removed.

On many projects, a precise deadline with a precise set of delivered functionality is not needed. Instead, the team simply needs to deliver high-quality software as fast as possible over a sustained period. If you’re in this situation, don’t take on the extra work of adding buffers to your project.

Ideally, an agile team begins an iteration with vaguely defined requirements and turns those vague requirements into functioning, tested software by the end of the iteration.

When multiple teams need to coordinate work, the release plan should be updated to show and coordinate the work of the next two or three iterations. The exact number of iterations will, of course, depend on the frequency and significance of the dependencies among teams. As iterations are completed, details about them are dropped from the plan. The release plan then becomes a rolling lookahead plan that always outlines expectations about the new few iterations.

A feeding buffer, like the schedule buffer of the previous chapter, protects the on-time delivery of a set of new capabilities. This is a somewhat complicated way of saying that if your team needs something from my team tomorrow at 8:00 a.m., my team shouldn’t plan on finishing it at 7:59.

To determine where feeding buffers are necessary, first allocate user stories among teams and iterations. Then look for critical dependencies between iterations and teams. Finally, add a feeding buffer only between these critical dependencies. That is, add a feeding buffer only if a team will be unable to do planned, high-priority work without the deliverables of another team. Even so, if the team can easily swap in other highly valuable work, a feeding buffer is unnecessary. Similarly, do not add a feeding buffer if the second team will be able to start making progress with a partial deliverable from the first team. If your team can start its work even if my team delivers only half of the planned functionality, a feeding buffer is not needed.

when multiple teams need to work together, it is often useful to add detail to their user stories sooner. The best way to do this is to identify the product owner’s conditions of satisfaction for a story. These are the things that can be demonstrated as true about a story once it is fully implemented.

The most important rule is that a team counts points toward velocity only for stories or features that are complete at the end of the iteration. Complete doesn’t mean something like “The coding is done, but it hasn’t been tested” or “It’s coded but needs to be integrated.” Complete means code that is well written, well factored, checked-in, and clean; complies with coding standards; and passes all tests.

There are three main problems with counting unfinished work. First, it is extremely hard to measure unfinished or incomplete work. Which is further along: A user story that has been programmed but has had no tests run against it or a story that has been partially programmed and partially tested? How far along is a programmer who has designed a solution for a story but hasn’t started coding it? We’re good at knowing when something hasn’t been started, and we’re fairly good at knowing when it’s done. We should assess work to be in one of those two states and leave it at that.

during an iteration a story is found to be larger than expected, it needs to be brought to the attention of the product owner. The product owner, in collaboration with the team, finds a way to split the story or reduce its scope such that a portion can ideally still be completed within the iteration, with the remainder moved to a future iteration.

There are four simple rules to keep in mind when drawing this type of burndown chart. • Any time work is completed, the top is lowered. • When work is re-estimated, the top moves up or down. • When new work is added, the bottom is lowered. • When work is removed, the bottom is raised.

The product owner selects how much of an iteration should be directed toward bug fixing rather than new feature development. The product owner and team then colloboratively select which bugs fit within that amount of time.

Individuals should be given every incentive possible to work as a team. If the team’s throughput is increased by my helping someone else, that’s what I should do. Team velocity matters; individual velocity doesn’t.

Teams should be reluctant to track the actual hours expended on tasks to get better at estimating. The risks and the effort to do so usually outweigh the benefits.

In selecting a range of velocity values, I typically consider up to the last eight iterations. Many teams stay together that long, but going back beyond eight iterations starts to feel like ancient history to me.

From these previous iterations, I look at three values. 1. The velocity of the most recent iteration 2. The average (mean) velocity 3. The average (mean) velocity of the three slowest iterations These three values present a good picture of what just happened, a “long term” average, and a worst-case of what could happen.

The release plan is updated either after each iteration or, at worst, after every few iterations.

Agile estimating and planning succeed because estimates of size and duration are separated. We start by estimating the size of a project’s user stories in story points. Because story points are abstract and notional, they are pure estimates of size. We then estimate a rate of progress, which we call velocity. Our estimates of size and velocity are then combined to arrive at an estimate of duration. Our estimating and planning process benefits from this clear and total separation of estimates of size and duration.

cycle time, the amount of time something takes to go from the start of a process to the end of that process. On a software project, cycle time is the time from when the team begins work on a feature until that feature delivers value to users. The shorter the cycle time, the better.

A key influence on cycle time is the variability in the time it takes to develop a new feature. One of the best ways to reduce variability is to work with reasonably small and similar size units of work.

Involve the whole team. Primary responsibility for certain activities may fall to one person or group, as prioritizing requirements is primarily the responsibility of the product owner. However, the whole team needs to be involved and committed to the pursuit of the highest-value project possible. We see this, for example, in the advice that estimating is best done by the whole team, even though it may be apparent that only one or two specific team members will work on the story or task being estimated. The more responsibilities are shared by the team, the more success the team will have to share.

Plan at different levels. Do not make the mistake of thinking that a release plan makes an iteration plan unnecessary, or the other way around. The release, iteration, and daily plans each cover a different time horizon with a different level of precision, and each serves a unique purpose.

Keep estimates of size and duration separate by using different units. The best way to maintain a clear distinction between an estimate of size and one of duration is to use separate units that cannot be confused. Estimating size in story points and translating...

Express uncertainty in either the functionality or the date. No plan is certain. Be sure to include an expression of uncertainty in any release plan you produce. If the amount of new functionality is fixed, state your uncertainty as a date range (“We’ll finish in the third quarter” or “We’ll finish in between seven and ten iterations”). If the date is fixed instead, express uncertainty about the exact functionality to be delivered (“We’ll be done on December 31, and the product will include at least these new features, but probably no more tha...

Replan often. Take advantage of the start of each new iteration to assess the relevancy of the current release plan. If the release plan is based on outdated information or on assumptions that are now false, update it. Use replanning opportunities to ensure that the project...

Track and communicate progress. Many of a project’s stakeholders will have a very strong interest in the progress of the project. Keep them informed by regularly publishing simple, very understandable indicators of the team’s progress. Burndown cha...

Acknowledge the importance of learning. Because a project is as much about generating new knowledge as it is about adding new capabilities to a product, plans must be updated to include this new knowledge. As we learn more about our customers’ needs, new features are added to the project. As we learn more about the technologies we are using or about how well we ar...

Plan features of the right size. Functionality that will be added in the near future (within the next few iterations) should be decomposed into relatively small user stories—typically, items that will take one or two days up to no more than ten days. We are best at estimating work that is all within one order of magnitude in size. Working with user stories that fall within these ranges will provide the best combination of effort and accuracy. It will also provide stories that are small enough to be completed during one iteration for most teams. Of course, working with small user stories can become quite an effort on longer projects. To balance this, if you are creating a release plan that will look more than two or three months...

Prioritize features. Work on features in the order that optimizes the total value of the project. In addition to the value and cost of features when prioritizing, consider the learning that will occur and the risk that will be reduced by developing a feature. Early elimination of a signficant risk can often justify developing a feature early. Similarly, if developing a particular feature early will allow the team to gain significa...

Base estimates and plans on facts. Whenever possible, ground your estimates and plans in reality. Yes, there may be times in some organizations when it will be necessary to estimate things like velocity with very little basis in fact, and Chapter 16, “Estimating Velocity,” presented some valid techniques for doing so. However, whenever possible, estimates and plans should be based on real, observed values. This goes, too, for an estimate of how much of a feature is complete. It’s easy to tell when a feature is 0% done (we haven’t started it), and it’s relatively easy to tell when we’re 100% done (all tests pass for all of the product owner’s conditions ...

Leave some slack. Especially when planning an iteration, do not plan on using 100% of every team member’s time. Just as a highway experiences gridlock when filled to 100% capacity, so will a development team slow ...

Coordinate teams through lookahead planning. On a project involving multiple teams, coordinate their work through rolling lookahead planning. By looking ahead and allocating specific features to specific upcoming iteratio...

“A single scale like that just tells us how strongly a user values a feature. It doesn’t tell us how strongly the user would react to the absence of the feature. I wouldn’t prioritize wheels very highly if you asked me about features on a car, but I’d be mad if you took them away.”