I agree that a “(verbal) Percent Complete” is not an effective measure of projects. A better percent complete measure can be based on the ratio of actual to estimate effort or store points. It should be a “derived” measure from direct output measures of a project. Its objective is to forecast project delivery date. Unfortunately, most managers are either not aware of the proper usage of the measure or just look for “easy” project management.

Yes, at the project level, one can say that if we have completed 100 story points out of 200 story points in the project, than we are 50% complete (assuming no story points are added or removed). The percentage is based on points completed vs. total points in the project. In fact, story points are great for this because they are disassociated from hours, which is one of the reason’s I prefer them. Thanks for the comment!

It is true that many waterfall efforts often end up with panic towards the end. That percent complete value looks like it’s stalled and not going anywhere.

But is that really a flaw of the metric? I posit that it’s either a problem in defining tasks or a problem of interpreting the metric.

If we define tasks to a finer level of fidelity and a collect a more complete set of tasks, the percent complete metric becomes more useful.

And if people didn’t make the invalid assumption of a constant velocity (n% reduced per day), then the percent complete metric becomes more realistic.

Abandoning this metric can have some benefits, which may be why you’re an advocate of “getting away” from it. Managers often fail to recognize that to define tasks to a fine level of fidelity, the development team must often spend time estimating instead of developing software. And that effort fundamentally contradicts the Agile Manifesto’s “working software over comprehensive documentation” value.

But sometimes the tradeoff is necessary. For example, I have worked on an XP project where in addition to the final working software, periodic progress metrics–including percent complete–were part of the contract-negotiated deliverables.

Did it slow us down? Yep. But it wasn’t useless. Even though they were intended for the customer, we ended up watching those metrics on a daily basis. They were far more motivating than placing an index card in a completed pile.

Furthermore, our customer was willing to pay a significant sum of money for the software and corresponding metrics. Yes, software is a creative endeavor, but even Shakespeare’s got to get paid.

One thing I could have been more clear on in the blog post, and I touch on this a little in the eBook, is that contracts are a special exception. If your customer requires a metric and even sweetens the pot (with money) to provide it, than it may be worth considering. However, as I stated in the eBook and the blog post, I still advocate understanding the rationale behind the metric. I would not think I was giving my client a good service if I did not get a good understanding for what they are trying to measure, EVEN if they are going to pay me more money to provide the metric. Thanks for the post!

[...] Getting Away from Percent Complete - There are many disadvantages to a “percent complete” philosophy in a Waterfall-style of software development as opposed to the Agile philosophy. [...]

In our organization, we call the managers who rely completely on the “percent complete” method as “MBS” – Managers By Spreadsheet. This becomes extremely frustrating and defeating to developers for a few reasons. First, they feel interrogated and pressured if their publish percent complete isn’t moving at a constant rate throughout the lifecycle. Next, they sometimes have normal work interruptions that are not recorded as explanations along with the percent complete. Finally, many of the projects they work on are not fully documented, so some of the effort is hidden in research and trial-and-error which makes the total effort variable.

A percentage assumes that one starts at 0% at the beginning of the project and ends at 100% at the end of the project. The percentages are obviously relative to some quantity of units (hours, storypoints, etc). The problem with the %-method occurs when that quantity changes during the project. In our organization, we’ve moved to an “Estimated Completion Date” method. This date may represent anything from delivery of prototypes to the full project. This method allows managers to schedule next tasks on completion of the current task, update stakeholders with realistic milestone/prototype dates, and creates a status that is relative to the current point in time. It gives the developer a self-imposed goal, reduces the need to constantly update spreadsheets with misunderstood statistics, and provides management with information for planning.

It has been years since we have asked for % complete! And everyone – managers, project sponsors, customers, developers, and QA – seems to benefit from the completion-date method.

Thanks for the contribution Eleshia. I think your observations about the “MBS” manager are dead on. I have also seen “MBS” managers (not necessarily project managers) manage people allocation across projects in the same way, which I find discouraging and will also write about in the future.

When you say “estimated completion date method”, it sounds like your teams (or developers) are committing themselves to a date that is a “self imposed goal”. Hopefully the trade off is that the developer gets to choose what they agree to deliver by their self imposed goal, much like Agile teams do for a sprints or iterations.

As an Agile Coach who found his way here from a link in Test Track, I have to take issue with the point made by another commentator to this article. The comment was made that development teams estimating instead of developing software contradicts the Agile Manifesto’s “working software over comprehensive documentation”. This is not correct.

Estimating is something required for any planning. Think about it. Everything is an estimate: story points, tasks, whatever. This has nothing to do with documentation. What this part of the Agile Manifesto is actually saying is that documentation for the sake of documentation is a waste of time. If most people will never read and it never be updated, where is the benefit. Put simple, it adds no real value. Kind of like percentage complete values.

Agreed Will. Not sure what Nathan was getting at with his comment. Without estimation there would be no way to plan, even at the iteration or sprint level. In fact, over the life of an Agile project, there may actually be more planning done than in a waterfall project where all the planning is done up front.

Will implies that estimation is not a form of documentation. I, however, assert that estimation is a form of documentation. That’s where our difference lies.

Documentation doesn’t merely mean a manual delivered to your end user(s). The more you estimate the comprehensive your documentation is becoming.

Comprehensive documentation (and estimation) isn’t necessarily bad. Will is right in saying, “estimation is something required for any planning.”

But the agile manifesto would tell us to question our actions, making sure our primary focus is on working software–not comprehensive documentation. (“That is, while there is value in the items on the right, we value the items on the left more.”)

Even if Will doesn’t agree with my assertion that estimation is a form of documentation, I will appeal to our common experiences.

Can we at least observe that estimation, in and of itself, is not working software?

Certainly one could successfully argue that estimation contributes towards working software and successful projects. But in that case, we should classify it as a tool. And then we’re stuck with preferring “individuals and interactions over processes and tools.” Again–not that tools are bad–but if we’re always preferring them over individuals and interactions then we’re probably doing something wrong.

In either case–documentation category or tool category–estimation is something to be questioned. And that’s probably why Alan wrote this blog post questioning the value of a particular metric.

And while I disagree with Alan in the sense that I do think that percent complete has value. I do not disagree with his questioning of the value of metrics we might collect unquestioningly.

It seems like we’re coming at this from different view points. I still do not see how estimation can be thought of in the same way as documentation – not matter how I look at it. Estimation is simply coming up with a value for how long you think something is going to take.

The practicalities of developing software in any organization – big or small – require that teams come up with these values as management need to have some idea of how long something is going to take in order for it to be complete and potentially shippable.

Development teams don’t just start coding in order to get to “working software”. There’s a planning part and this is where estimation comes in. Yes. Estimation is not working software. Whether someone decides to call it a tool or not is redundant.

I also question the skewed meaning taken “individuals and interactions over processes and tools”. This relates more to hiding behind technology than having to deal with people face to face – still a huge problem for many developers in my experience. And when developers/teams do talk to each other they are still working out in their heads how long they think something is going to take and that leads us right back to estimation.

If we were building brick walls, we could come up with a “percent complete”, by using a tape measure.

With software, and especially with RAD frameworks, it’s really easy to fool management, or even the coders, into thinking things are “90% complete” just because the screens look pretty.

Quite often, like nearly always, things stall at 90+% as we find out the customer wants something quite different, or more complex, or the app is too slow, or it’s crashing, or the app framework can’t be coaxed to do the last 10% at all.

Not to mention that testing with real users often reveals another 100% of work needed to find and fix the bugs.

Software is done when its done, to everyone’s satisfaction. No amount of massaging project plans can make it 1% closer to completion.

We’d see more progress if the project manager, instead of focusing on how complete it is, came around and asked “What can I do to help move things along?”. That’s almost never asked. Quite often things would go much faster if some beaurocratic stumbling block was removed.

Hacker, you hit the nail on the head. Great leaders are built to serve, not command and control. Facilitate the team’s success by removing obstacles, then get out of the way. PM’s who focus on percent complete, become an obstacle.

Will, agree with your point on “individuals and interactions over process and tools”. Agile teams don’t look for tools to define how they work, instead they do the opposite. Work out the people issues first, then use tools and process to fill the gaps.

An interesting metric to capture would be the length of time the average project in an organization goes from zero to 20% complete vs. 80-100% complete.