Joshua Herzig-Marx

Earned value, percent complete, and other measures of work performed on a project have always seemed useless. Perhaps that’s why I like Scrum so much–it only requires participants to estimate the hours of work remaining. Johanna Rothman wrote a short but important piece: Managing Product Development: There is No Such Thing as Percent Complete. While some of the comments are critical, I think they highlight the real challenges of giving a percentage. To pull out two:

The difference between Physical Percent Complete and Percent Complete needs to be clarified. On software projects where the delivered features are produced through Work Packages the comcept of Physical Percent Complete can be used. (Glen B. Alleman)

This is only a problem if you take the percentage as a percentage of time. A percentage of requirements fulfilled works just fine. (Michael Lucas Smith)

To be confident in % complete, you need to be confident in your estimates, in the amount of work completed, in the amount of work remaining, and in the speed at which the remaining work can be completed. That’s a lot of moving parts and merely watching the percentage change over time provides little insight into those underlying numbers.

When you ask a team member for percent complete, you’re generally only trying to learn two things: when will their work be completed and how will that timeline affect other parts of the overall project. Ask only the questions you need answered and you’re more likely to get the answers you need. The fact that it takes less effort to answer smaller and narrower questions is just gravy.

Photo by juliehicks75