Agile developers essentially say: We will give you a plan based on what we know today; we will adapt the plan to meet your most critical objective; we will adapt the project and our plans as we both move forward and learn new information; we expect you to understand what you are asking for—that flexibility to adapt to changing business conditions and absolute conformance to original plans are incompatible objectives.
Many traditional planners don’t understand a key concept—you can’t “plan” away uncertainty. Plans are based on what we know at a given point in time. Uncertainty is another way of expressing what we don’t know—about the ends or the means.
For most uncertainties (lack of knowledge) the only way to reduce the uncertainty and gain knowledge is to execute—to do something, to build something, to simulate something—and then get feedback.
Many project management approaches appear to be “plan, plan, plan-do.” Agile approaches are “plan-do-adapt,” “plan-do-adapt.”
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.
If I were to define a failed project, one of my criteria would certainly be “a project on which no one came up with any better ideas than what was on the initial list of requirements.”
Obviously, though, we can rarely wait twenty years for a system, and so we engage teams. A team of thirty may spend a year (thirty person-years) developing what a lone programmer could have done in twenty. The development cost goes up, but the value of having the application nineteen years earlier justifies the increased cost.
Far too often a plan is reduced to a single date, and all of the assumptions and expectations that led to that date are forgotten.
In other words, an early start requires a combination of things to go well; a late start can be caused by one thing going wrong.
Loading everyone to 100% of capacity has the same effect as loading a highway to 100% of capacity: No one can make any progress.
The best way of dealing with uncertainty is to iterate. To reduce uncertainty about what the product should be, work in short iterations, and show (or, ideally, give) working software to users every few weeks.
A problem with traditional planning can arise if the project team or its stakeholders equate estimating with committing. As Phillip Armour (2002) points out, an estimate is a probability, and a commitment cannot be made to a probability.
Macomber (2004) points out that we should not view a project solely as the execution of a series of steps. Instead, it is important that we view a project as rapidly and reliably generating a flow of useful new capabilities and new knowledge.
A project is at risk if its planning extends well beyond the planner’s horizon and does not include time for the planner to raise her head, look at the new horizon, and make adjustments.
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.
A key tenet of agile estimating and planning is that we estimate size but derive duration.
On a software project, ideal time differs from elapsed time not because of timeouts, incomplete passes, and injuries, but because of the natural overhead we experience every day.
When considerations of organizational overhead are ignored, ideal days can be thought of as another estimate of size, just as story points are.
It is possible to put too much effort into estimating, with the result being a less accurate estimate.
Planning poker combines expert opinion, analogy, and disaggregation into an enjoyable approach to estimating that results in quick but reliable estimates.
ideal-day estimates need to change when the team becomes better at something.
There is credible evidence that we are better at estimating “this is like that” than we are at estimating the absolute size of things (Lederer and Prasad 1998; Vicinanza et al. 1991).
Teams that estimate in ideal days almost inevitably have their ideal days compared with actual days. They then find themselves justifying why they completed “only” eight ideal days of work in a ten-day iteration.
At the start of a project there is some amount of uncertainty about what features the new product should contain. There is also uncertainty about how we’ll build the product. Laufer (1996) refers to these types of uncertainty as end uncertainty and means uncertainty.
A project following a waterfall process tries to eliminate all uncertainty about what is being built before tackling the uncertainty of how it will be built.
End uncertainty does not need to be eliminated at the outset (as hoped for in the traditional view), and it cannot be. However, one of the greatest risks to most projects is the risk of building the wrong product.
The high-value, high-risk features should be developed first. These features deliver the most value, and working on them eliminates significant risks.
Because there is rarely enough time to do everything, we need to prioritize what is worked on first. There are four primary factors to be considered when prioritizing. 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.
The return on a project can come from a variety of sources. For convenience, we can categorize these as new revenue, incremental revenue, retained revenue, and operational efficiencies.
Decisions about who works on what and the sequence of activities are best left to the individuals working on those tasks and are best deferred as long as possible.
It is not necessary to estimate everything that a product owner may ever want. It is necessary only to have an estimate for each new feature that has some reasonable possibility of being selected for inclusion in the upcoming release.
What I find to be a good compromise is to place specific work into the first one to three iterations, treating the rest of the release plan as one large bucket.
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.
When individuals sign up for specific tasks at the beginning of the iteration, it works against fostering a unified commitment to achieving the goals of the iteration.
The iteration goal is a unifying statement about what will be accomplished during the iteration. It does not have to be very specific. For example, “Make progress on reports” is a good iteration goal.
because tasks are not allocated to specific individuals during iteration planning, it is impossible to ask the specific person who will do the work.
even though we expect a specific individual will be the one to do a task, and even though he may know the most about that task, it does not mean that others have nothing to contribute.
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.
when the person who will do the work provides the estimate, the person’s pride and ego may make him reluctant to admit later that an estimate was incorrect. When an estimate is made collaboratively, this reluctance to admit an estimate is wrong goes away.
most teams are successful when their planned work (the sum of their task cards) represents between four and six hours per day.
Because too few stories are completed in a single iteration for these to average out, I prefer not to use velocity when planning an iteration. However, because these differences do average out over the course of a release, velocity works extremely well for release planning.
the length of time that priorities can go unchanged is a factor in selecting the iteration length.