What do you do when management asks for a percentage complete on an Agile project?

4 Answers 4


The idea of percentage complete doesn't usually exist on an Agile project.

For tasks, the work is usually viewed as "done" or "not done". The most granular I would get is "not started", "started" or "in progress", and "done". As soon as a task is done, you earn credit for it on the given iteration.

For projects, the purpose of iterations is to make progress visible to stakeholders. In theory, the project can be terminated after any iteration that delivers a product that satisfies the needs of the stakeholders and proceeding into another iteration would deliver less value than the iteration is worth.

You need to determine what management is looking for when they ask for a percent complete.

If they are asking for an estimated duration before the backlog is finished, you can estimate that if you have a stable velocity. Achieving a stable velocity usually takes several iterations, but if you can estimate (at least roughly) the size of items in the backlog, then you can determine how many iterations (approximately) it will take to complete all of the items.

If they want to know how much work has been done to-date, that can be presented in terms of completed tasks from the backlog or a ratio of completed tasks to items still in the backlog.

There is a problem with using the product backlog to provide information, however. The product backlog may change at any point in time, and adding or removing items would change your reporting. It would also require estimating the entire product backlog, instead of just the most important backlog items, which may not be accurate until the items are well understood and defined.

The person responsible for the process (in Scrum, the Scrum Master; in Disciplined Agile Delivery, the Team Lead) should be working with external stakeholders to educate them on the process and to ensure they are getting the information that they need. There won't be a 1:1 mapping between the metrics for monitoring a plan-driven project and an agile project, but it's likely that one or more measurements or metrics can be provided to address an information need.

  • +1 Nice post. Though I would question that in Scrum the Scrum Master is always the one responsible for ensuring stakeholders get the information they need. In a lot of Scrum Teams the Product Owner owns the communication with the stakeholders. Mar 10, 2016 at 16:25
  • @BarnabyGolden It depends on the information. Yes, the Product Owner is the one who communicates with external stakeholders. However, the Scrum Master is the keeper of the process. I would suspect that process and project metrics would be monitored by the Scrum Master, who would make sure that they are available for internal stakeholders and for the Product Owner to deliver to external stakeholders, as appropriate. Like in most things, I would expect the Development Team, as a whole, to contribute to maintaining any data or reporting measures and metrics.
    – Thomas Owens
    Mar 10, 2016 at 16:27
  • 1
    @BarnabyGolden: It would be up to the Scrum Master to educate the external stakeholders that their literal question isn't meaningful in scrum and what meaningful alternatives there are. It would then be the Product Owner to communicate the actual information with the external stakeholders. Mar 12, 2016 at 15:22

Something a lot of the online agile do poorly is the Burn Down Chart. It's an essential part of communication to management and allows you to answer the age old question "So, when will you be done?"

First answer back is a question- Scope Driven or Schedule Driven. Now since Scope driven is very uncommon and even when it happens, almost always becomes schedule, we'll stick with schedule driven for this answer.

So you have a release date, let's say six months from now. Engineering then makes a guess (we call it estimating, it's nothing more than a guess though) on how much work they can get done in the first sprint. This is then used to guess how much work can be done in the total release. For sake of this example we'll call that 500 points.

Then we stop guessing and we start using velocity reports. Every sprint you subtract the story points delivered, from the projected release. This creates a trendline that can be used to very easily and visually see if you're going to deliver all the value by the release date. It also starts predicting this right away. No more projects being 90% complete and green right up until they are bright red and three months late.

If your velocity falls off, then you get to decide if you cut scope or increase the schedule. In agile, the suggestion is to cut scope because you can always add more time later, but you can never get time back.

I should really update my Scope vs. Schedule in Agile slideshare presentation to include Burn Down charts. For a good video on projecting down, I suggest Henrik Kniberg's Product Owner Video. The 'When will you be done' part starts about 11:50, though watching the rest of the video helps for context.


It's impossible to give a "percent complete" number, but you can give a ballpark estimate. The bigger the estimate, the less accurate it will be. For example, if you only have a weeks worth of work left, you're likely within +/- 10% of the truth. If you seem to have four months of work left you could easily be off by 50%, 100%, or even more.

That being said, a very rough approximation is simple. Presumably you have a backlog, and that backlog is complete (ie: you have stories and/or epics that cover what you're trying to accomplish). Also, presumably these stories and epics have points associated with them. They won't all be accurate points, but they are a place to start.

The amount of work done, then, is the number of points completed divided by the total number of points estimated.

The important thing to remember with Agile, however, is that this number is not set in stone. You could be 50% done this week, and 40% next week even though you've finished stores in the mean time. It's important to remember that Agile isn't designed to give us accurate estimates, it merely serves to add more transparency, and to be prepared for change early rather than surprised by change late.


For a user story there is no such thing as a percentage complete. It has binary state Done or Undone. Which is determined by "Definition of Done". 99% complete is undone.

There is few methods to track the progress in sprint, release or project perspective.

  1. Burndown chart, both project and sprint. http://www.methodsandtools.com/archive/scrumburndown.php https://www.scrumalliance.org/community/articles/2013/august/burn-down-chart-%E2%80%93-an-effective-planning-and-tracki

Burndown chart

  1. Cumulative flow diagram. http://brodzinski.com/2013/07/cumulative-flow-diagram.html http://www.slideshare.net/yyeret/explaining-cumulative-flow-diagrams-cfd

Cumulative Flow Diagram

  1. Agile EVM http://www.methodsandtools.com/archive/archive.php?id=61

Agile EVM

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.