«    »

Predictability and Planning for Done

There is an interesting relationship between having predictable estimates for project management and using a thorough definition of done.

Achieving the full definition of done for a feature or release (often called being done-done) is surprisingly difficult. You may have heard the anecdotal rule of thumb that it takes 80% of the time to achieve 80% complete on a feature, and another 80% time-wise to achieve the remaining 20%. This is not due to using a strict definition of done. Anyone who has worked on an undisciplined waterfall project that has 'finished' coding the functionality and is now in test knows that sinking feeling of having defect after defect reported with no end in sight – and hence no predictability.

Using an imprecise or overly-simplistic definition of done will definitely impede predictability because you have only a vague idea of what the current state of your software is, and hence have high uncertainty regarding your progress to date.

Using a specific definition of done combined with the lean principle of minimizing work-in-progress greatly improves your knowledge of the current state of your software and hence your progress. Most of the uncertainty has been driven out by forcing work to done-done. This is not enough, however, to improve the predictability of your budget or schedule estimates for your outstanding work. You need to ensure your planned tasks and estimates include everything required to get to done-done.

On my last project, we tried just tracking coding tasks in the sprint plan. The remaining effort to get to done-done was treated as part of the general overhead that was used to calculate our velocity. This provided poor predictability in terms of both budget and schedule, especially as a feature neared code-complete. The estimate on the remaining coding tasks approached zero, but the time required for reviews, testing, and fixes remained roughly constant, thus exceeding what could be accounted for by velocity.

We then started to track most checklist items from our definition of done as individual tasks for each feature in addition to the regular coding tasks provided by the developer(s). This worked better, but we still suffered predictability problems as the feature went through review and test. Defects discovered had to be fixed, impacting the schedule and budget for the feature.

The next tweak we made was to allocate time up front for these fixes by adding an entry titled "Anticipated Issues" to each feature that provided an allocation of effort (budget, from which schedule was derived) that could be used to address defects, review corrections, poorly estimated tasks, and discovered work. The amount of effort allocated to this item was estimated per feature based on the size and complexity of the feature and the experience and quality level of the developers working on the feature.

Our most recent adjustment was to the front-end of feature development. Over several sprints, we noticed a trend that when developers started a new feature, especially one that was significantly new, they often had a day or even two where they did not make the expected progress on their tasks. We eventually determined that developers consistently had to spend time familiarizing themselves with the feature, especially learning the requirements and getting clarifications regarding how the feature was to be implemented, and that they virtually never allocated time in their tasks / estimates for this. So we added a new task to each feature named "Feature Clarification" to make this explicit.

By planning for all the components of our definition of done, we have achieved much better predictability. While our variance from our estimates per feature remained fairly high, the average variance across features was much closer to the original estimate, rather than being consistently over. As progress is made on a feature, we have much better estimates and better visibility into the outstanding work.

If you find this article helpful, please make a donation.

«    »