Agile Estimating and Planning

by Mike Cohn

A linear feature is one for which “the more, the better” holds true. The bigger the hotel room is, the better. These are called linear features because customer satisfaction is correlated linearly with the quantity of the feature. The better one of these features performs (or the more of it there is), the more satisfied the customers will be. Because of this, product price is often related to linear attributes.

Finally, exciters and delighters are those features that provide great satisfaction, often adding a price premium to a product. However, the lack of an exciter or delighter will not decrease customer satisfaction below neutral.

exciters and delighters are often called unknown needs because customers or users do not know they need these features until they see them.

The arrow through the bottom right of this diagram shows that once some amount of a must-have feature has been implemented, customer satisfaction cannot be increased by adding more of that feature. Also, no matter how much of a must-have feature is added, customer satisfaction never rises above the midpoint.

On the other hand, the line in the top left shows that customer satisfaction rises dramatically based on even a partial implementation of an exciter or delighter. Finally, the line through the middle shows the direct relationship between the inclusion of linear features and customer satisfaction.

A product’s must-have features do not need to be developed in the first iterations of a release. However, because users consider these features to be mandatory, they need to be available before the product is released. Keep in mind, though, that partial implementation of must-have features may be adequate, because gains in customer satisfaction drop off quickly after a base level of support for threshold features has been established.

Secondary emphasis should be placed on completing as many linear features as possible. Because each of these features leads directly to greater customer satisfaction, the more of these features that can be included, the better (excluding, of course, such situations as a product that is already bloated with too many features). Finally and with time permitting, at least a few delighters should be prioritized such that they are included in the release plan.

Split large stories along the boundaries of the data supported by the story.

Split large stories based on the operations that are performed within the story.

Split large stories into separate CRUD operations.

Consider removing cross-cutting concerns (such as security, logging, error handling, and so on) and creating two versions of the story: one with and one without support for the cross-cutting concern.

Consider splitting a large story by separating the functional and nonfunctional aspects into separate stories.

Separate a large story into smaller stories if the smaller stories have different priorities.

Don’t split a large story into tasks. Instead, try to find a way to fire a tracer bullet through the story.

It can very possibly be appropriate to fix a bug or address an old issue while working on a separate issue in the same part of the code. However, the prioritiy of doing so needs to be considered in the same manner in which priorities were considered for other features. In other words, which is higher priority: spending half a day fixing a year-old bug or spending the same amount of time on something else?

Avoid making things worse by adding related changes to an appropriately sized feature unless the related changes are of equivalent priority.

the product owner’s conditions of satisfaction are defined by a combination of schedule, scope, and resource goals.

Projects are typically either date-driven or feature-driven. A date-driven project is one that must be released by a certain date but for which the feature set is negotiable. A feature-driven project is one that we would probably like to release as soon as possible but for which we consider the completion of a set of features to be more important.

If the project is feature-driven, we can sum the estimates of all needed features and divide by the expected velocity. This will give us the number of iterations necessary to complete the desired functionality.

If the project is date-driven, we can determine the number of iterations by looking at a calendar. Multiplying the number of iterations by the expected velocity will tell us how many story points or ideal days will fit in the release. We can count off that many points or ideal days into the prioritized list of user stories and see how much functionality can be delivered in the desired time.

While planning an iteration, tasks are not allocated to specific individuals. At the start of the iteration, it may appear obvious who will work on a specific task; however, based on the progress of the whole team against the entire set of tasks, what is obvious at the start may not be what happens during the iteration.

The primary purpose of iteration planning is to refine suppositions made in the more coarse-grained release plan.

Creating the iteration plan leads a team into discussions about both product design and software design.

Product design discussions, for example, may be around topics such as the best combination of stories for optimizing value, interpretation of feedback from showing working software to customers, or the extent to which a desired feature should be implemented (that is, will 20% of the feature and effort deliver 80% of the value?).

Software design discussions may, for example, involve the appropriate architectural tier in which to implement a new feature, which technologies should be used, wh...

One source of changes to priorities is the iteration review meeting, which is held after an iteration is finished.

With their priorities and target velocity in mind, the team identifies a goal they would like to achieve during the iteration. The goal succinctly describes what they would like to accomplish during that period.

The iteration goal is a unifying statement about what will be accomplished during the iteration. It does not have to be very specific.

Once the appropriate set of user stories has been selected, each is decomposed into the set of tasks necessary to deliver the new functionality.

A common question around iteration planning is what should be included. All tasks necessary to go from a user story to a functioning, finished product should be identified. If there are analysis, design, user interaction design, or other tasks necessary, they need to be identified and estimated. Because the goal of each iteration is to produce a potentially shippable product, take care to include tasks for testing and documenting the product. Including test tasks is important because the team needs to think right at the start of the iteration about how a user story will be tested.

You should identify, estimate, and include tasks for meetings related to the project. When estimating the meeting, be sure to include the time for all participants, as well as any time spent preparing for the meeting. Suppose the team schedules a meeting to discuss feedback from users. All seven team members plan to attend the one-hour meeting, and the analyst plans to spend two hours preparing for the meeting. The estimate for this task is nine hours. I usually enter this into the iteration plan as a single nine-hour task, rather than as a separate task for each team member.

Does that mean that working out of the natural order will cause the project to take longer? Two answers: Probably not, and it doesn’t matter.

task estimating on an agile project should be a group endeavor.

hearing how long something is expected to take often helps teams identify misunderstandings about a user story or task. Upon hearing an unexpectedly high estimate, a product owner or analyst may discover that the team is heading toward a more detailed solution than necessary. Because the estimate is discussed among the team, this can be corrected before any unneeded effort is expended.

The product owner, analysts, and user interface designers may discuss product design, how much of a feature should be implemented, and how it will appear to users. The developers may discuss options of how they will implement what is needed. Both types of design discussion are needed and appropriate.

those discussions for outside iteration planning It’s not necessary to go so far as drawing a design, because all that’s necessary at this point are guesses about the work that will be needed to complete the features. If you get into the iteration and discover the tasks are wrong, get rid of the initial tasks and create new ones. If an estimate is wrong, cross it out and write a new value.

we know the estimates are wrong; they are, after all, estimates, not guarantees. For these reasons, we cannot expect this team to sign up for 560 hours of tasks. In fact, most teams are successful when their planned work (the sum of their task cards) represents between four and six hours per day. For our team of seven people, working two-week iterations means they can probably plan between 280 and 420 hours.

Before committing to the work of an iteration, the team needs to look at the tasks and get a feel for whether they represent an appropriate distribution of work based on the various skills within the team.

The more uncertainty of any type there is, the shorter the iterations should be. When there is a great deal of uncertainty about the work to be done or the product to be built, short iterations allow more frequent opportunites for the team to measure its progress through its velocity and more opportunities to get feedback from stakeholders, customers, and users.

Once a development team commits to completing a specific set of features in an iteration, it is important that they not be redirected from that goal. It is, therefore, important that the product owner not change priorities during the iteration and that she help protect the team from others who may attempt to change priorities.

the time from new idea to working software will be an average of 1½ times the length of the team’s iterations.

follow a macro-cycle of six two-week iterations followed by a one-week iteration. I refer to this cycle as “6 × 2 + 1.” During the two-week iterations, the team works on items prioritized by the product owner. During the one-week iteration, however, the team chooses its own work. That doesn’t mean it’s play time or a week at the beach. Rather, the individuals on the team use this time to focus on what they view as priority work for the project. Programmers may perform refactorings they felt were too risky in the middle of other iterations or experiment with relevant new technologies. A tester may catch up on automating legacy manual tests. An analyst may work on an upcoming large feature that she feels hasn’t received enough attention.

Calculate the average velocity for the iterations you’ve run. Then, for each iteration completed, move one step to the right on the cone of uncertainty. So for a team that has run one iteration, use the range for the “initial product definition” milestone. If the team has run two iterations, use the range for the “approved product definition” milestone (80% to 120%), and so on.

most individuals who are assigned full time to a project spend between four and six hours per day on that project.

it is useful to include a buffer in the determination of the schedule. A buffer is a margin for error around an estimate. In cases where there is significant uncertainty or the cost of being wrong is significant, including a buffer is wise. The buffer helps protect the project against the impact of the uncertainty. In this way, buffering a project schedule becomes an appropriate risk management strategy.

No more than 70% of the planned effort for a project can be targeted at Must Have requirements. In this way, DSDM projects create a feature buffer equivalent to 30% of the duration of the project.

The schedule buffer is the square root of the sum of these squares.[

The project buffer should represent at least 20% of the total project duration. A smaller buffer may not provide adequate protection for the overall project.

it is often appropriate to use multiple buffers, because we are protecting the project against multiple types of uncertainty.

we buffer feature uncertainty with features and schedule uncertainty with time.