Section 7.3. Planning Smells

7.3. Planning Smells

7.3.1. Unmet or Unachievable Plans

Symptoms

Although situations may arise that make the team unable to meet the plans for an iteration, this should be the exceptionnot the rule. If plans are regularly unmet, there is something wrong either in the planning process or in how the iteration is being managed.

Possible Process Innovations

Blitz Planning, Planning Game, Iteration Planning Game, or Sprint Planning Meetings

If the team feels that the plans are unachievable at the beginning of the iteration, then the planning process needs to be addressed. Two stages of planning may be at fault: the process of selecting functionality for the iteration or the process of defining the tasks necessary to build that functionality. Either of these processes could be producing unrealistic plans. Using one of the standard planning strategies listed above may eliminate the problem.

It's important to notice that the process of defining the tasks provides feedback about the quality of the process for selecting the functionality. For example, consider an iteration whose selected functionality consists of three features whose estimates sum to 20 ideal engineer hours, which fits into the velocity for this iteration. The team then decides there are six tasks that must be completed to build those three features. There is a chance that the sum of the estimates of those six tasks is greater than 20 and does not fit into the velocity for this iteration. Instead of reducing the estimates to meet the "commitment" to those features, the team should reestimate the features and initiate a conversation with the customer to renegotiate the content of the iteration. It is much better to recognize the situation and deal with it on the first day of the iteration than to hope for heroics from the team and miss the commitment at the end of the iteration.

Individual Estimation Techniques

Sometimes the problems with a plan are rooted in the inaccuracy of the estimates that the team is making. This may be the case if all of the planning sessions seem to be following a process and the team believes in those plans at the beginning of the iteration. Look at the previous couple iterations to see what percentage of tasks were inaccurately estimated. If the inaccurate estimates can be traced to individuals, helping those individuals to improve their estimates may eliminate the problem.

Group Estimation Techniques

Measuring the difference between estimated and actual effort over a number of iterations will give a measure of the team's estimation accuracy. If that accuracy is too low, changing the estimation process to allow broader input may improve accuracy.

Change Estimation Units

If the team continues to make inaccurate estimates, changing the estimation units sometimes improves accuracy.

Limited Steering vs. No Distractions

If the plans created at the beginning of the iteration seem achievable and estimation accuracy is high, it is possible that engineers are being asked to work on tasks not related to the iteration goals or that changes to those goals are being allowed during the iteration. The plans should include everything that the engineers will do during that iteration, and distractions should be eliminated in order to allow them to succeed.

Burn-down Chart and Informative Workspace

Techniques that allow the team and other observers to see the progress being made during an iteration can facilitate early detection of detractors so that those problems can be eliminated before they threaten the success of the iteration.

"Anonymous" Early Warnings

If the unmet commitments happen late in the iteration, it is possible that they could have been reported (and the team could have adjusted) earlier in the iteration. If there has been a climate of fear, anonymity (even if it isn't real) can encourage individuals to report problems earlier and begin to rebuild the trust that agility requires.

7.3.2. Extensive Replanning

Symptoms

Although replanning is a necessary side effect of learning more about what needs to be done, it can require significant resources and can disrupt the progress of the project. When a plan doesn't last longer than about one quarter of its length, you are replanning too often.

Remember that there are three levels of plans: release plans, iteration scope plans, and iteration plans. The level of detail increases as we progress through these planning activities. One source of replanning is having too much detail in the longer-term plans. The further away something is from being built, the less we know about it and the less detail we need (or want) in planning it. If you are regularly revising your long-term plans, they probably have more detail than your current knowledge warrants, and you should reduce the level of detail in them.

Possible Process Innovations

Burn-down Chart

When one engineer realizes that a task is going to take longer than expected, team leaders often feel the need to replan. However, tracking progress can give the team a feeling as to whether there is time available to recover from this situation. Given that information, the team can generally adjust when necessary without the need for official replanning at all.

Limited Steering vs. No Distractions

Replanning in the middle of an iteration can be caused by two things: the team learns something that changes their estimates significantly, or the customer asks for new functionality. When the team realizes they are not going to be able to meet the plan for an iteration, you have no choice but to do some sort of replanning. Try to keep it as simple as possible. However, you do not have to allow the customer to ask for new functionality. One strategy to prevent these kinds of replanning is to not allow anyone (customer, management, etc.) to change what the team is developing in the middle of an iteration. Although this obviously prevents replanning, it can also greatly improve the team's focus and therefore its ability to deliver.

Pipelining Iterations

Sometimes pipelining iterations can give the team the ability to research or prototype an architecture before the iteration in which it will be required. This can help you give estimates that are more accurate when you plan the iteration, which can help prevent replanning.

Change Iteration Length

If you are changing the iteration plan in the middle of an iteration in order to accommodate a customer request, one strategy can be to shorten the iteration length. If your iterations are a month long, but your customer needs to be able to request functionality and have it delivered within two weeks, then you'll have to replan in the middle of the iteration. If you change your iteration length to a week, then your customer can always put his new request into the next iteration, and you can meet his time requirements.

7.3.3. Lack of Long-term Vision

Symptoms

The focus on the current iteration can leave the team somewhat shortsighted. Although this has some positive effects, it can have two negative effects. First, it can leave the team with the feeling that there is no end in site. The engineers can begin to feel that every iteration is the same and that the iterations will go on forever. Second, the customer and the team can become focused on the little details of the functionality in the system while losing sight of other capabilities that would improve the value of the system.

It is important to remember, though, that any long-term planning is highly speculative and should not influence the designs being developed for the current iteration. Remember, in this iteration, we code only what we need for this iteration's functionality. We do not architect the system for requirements that we think might be coming later in the project.

Possible Process Innovations

Blitz Planning

Blitz planning is a strategy used to find all of the functionality the system will require and then, very roughly, divide that functionality into releases. Although it only requires a couple of hours, it can give the entire team good perspective on the project in the long term.

Backlogs

Maintaining a backlog with all of the functionality that people think might be in the system helps everyone (customer and team) focus on the bigger picture when selecting functionality to be developed in the current iteration. This can help prevent the team from tweaking existing features when implementing new features would be more cost-effective.