While there are many misconceptions about Agile, a significant concern for organizations unfamiliar with the methodology is how to track the progress of teams on Agile projects.


One temptation is to cope with this uncertainty by shoehorning the familiar Waterfall-based project management measures of cost assigned to arbitrarily defined milestones within an Agile schedule. This can burden the project with unnecessary reporting while not providing any meaningful visibility into actual progress toward success.

When implemented well, Agile provides ways to measure both productivity and quality of projects. Understanding the principles behind how these are measured can provide stakeholders and managers with a high level of ongoing visibility of progress and early identification of potential problems.


Central to Agile is the deconstruction of work into epics and user stories, which are added to the backlog for development. Each user story is further broken down into use cases, which are then estimated based on story points.


The art form in Agile estimation is understanding how much work each story point will take a developer, which is something the team leads and managers refine over time.This apparent variability can cause angst with stakeholders early in a development project if they don’t understand that each iteration rapidly increases the accuracy of estimation on a project.



The initial backlog gives an overview of the amount of work to be completed in the Agile project. A burndown chart illustrates how much progress the team has made after - and even during - every iteration.


A practiced team will be able to more accurately estimate the rough number of use cases and even approximate story points, giving a high fidelity to work completed on a daily basis. For teams newer to Agile, tracking often focuses on use cases or even user stories and estimated level of completion until confidence in the ability to estimate increases.



A key measure of Agile productivity is velocity, which is where the design-centric approach melds with team performance. Simplistically, velocity is the number of story points completed by a team in a time period.


It’s common for velocity to increase during a project, as teams form strong working relationships and become more familiar with their project and customers.


It’s important for velocity that the base unit – for example, a story point – is consistent in terms of effort and complexity. This takes some practice from the designers and Agile team leaders.



Because Agile projects start with a broad definition of customer requirements and specifications, continuous verification and validation of quality is essential during development.


A common mistake with Agile is to only introduce quality assurance (QA) into the development teams at the end of projects, or keeping them separate completely, rather than embedding QA into development teams from the start. While this is a typical Waterfall project practice, in Agile, the QA team members are embedded alongside the developers and participate as peers in the sprint planning, execution, and completion.

The end of every Agile iteration (for example, a sprint in Scrum) involves a demonstration of working software, ideally validated by end user representation. Acceptance by the end user moves the story to completion; rejection returns the story to the backlog as rework.


It’s essential the Agile team leads ensure these demos provide honest, constructive feedback without being subject to continuous design changes.




If there is repeated lack of clarity from the end user, the user story needs to be refined in design before being moved into the backlog for development. Techniques such as Kanban help visually track stories as they move from backlog to release – and also when they return to the backlog for rework.

The key indicator of quality is the rework rate, which is the number (and number of times) a use case or story is returned to the backlog for additional work or redesign. This is important as rework effectively slows velocity.


If quality is not tracked, "productivity" can remain high even while less progress is being made.


Cost and Effort

In traditional Waterfall, progress is tracked against various milestones for consumption of schedule, cost, and effort; none of which are necessarily good proxies for productivity or quality of the work delivered.


In Agile, with the focus being on progress measured through productivity and quality, the effort and cost are derived from the time recording system.


Projecting the future costs and completion becomes more accurate as confidence in estimation and velocity increases. Further, tracking rework and changes in business priorities – two strengths of Agile – can help adjust the backlog to prioritize the capabilities most important to the business.


Managing Agile for Success

Understanding Agile and how to measure progress can help project stakeholders and managers properly scope and define a project and team, as well as provide a high degree of visibility into progress and the opportunity to identity and rectify potential issues early. This knowledge can overcome concerns about adopting Agile and help instill a culture of productivity and quality within the organization.


To learn more about Agile methodology in practice, download our "Agile Practitioner's Guide."

RG provides program leadership for Agile enterprise programs. Find out more here. Liam Speden is RG’s Chief Technology Officer, previously a start-up CEO and formerly a product line manager for Autodesk in San Francisco. He has been practicing rapid development software engineering for over 30 years, including Agile and its precursors, on projects ranging from 3 to 300+ people.

Join the Conversation

If you have any questions or feedback please fill out the comments below.