Agile Metrics and KPI’s

For agile teams, it’s important to track and monitor the team’s progress to see how requirements translate into working product. Key performance indicators (KPIs) are indicators that show how well a project is going. 

Related methods and techniques to Agile Metrics and KPI’s

  • Burndown and Burnup chart

    1. Burndown and Burnup chart

    Burndown or Burnup charts show how much work has been completed and how much work is remaining as the iteration progresses.

    Burndown and Burnup chart present the same data in a different way. Teams choose how they would like to see their data.

    Some teams combine burndown and burnup charts into one chart. The chart shows the remaining actual story points as well as the completed cumulative story points.

  • Planned versus Actual Velocity

    2. Planned versus Actual Velocity

    Planned versus Actual Velocity is a forecasting tool based on the on the observed and actual performance. The team can tell the customer whether they will finish the backlog of user stories by the planned number of iterations or not.

    Planned vs. actual velocity is a predictive tool based on observations and actual performance. It enables the team to tell the customer if they will complete the backlog of user stories before the planned number of iterations.

    The planned velocity is the team's expectation of the story points to be delivered in each iteration. Actual velocity refers to actual sum of the story points that they delivered in each iteration.

  • Parking Lot Chart

    3. Parking Lot Chart

    The parking lot diagram represents a team's progress in completing story points for a release.
    The parking-lot visual information is useful for tracking and diagnosis.

  • Little’s Law

    4. Little’s Law

    Little's Law states that the size of a queue (the number of items in WIP status) is proportional to the duration of time in the queue. Therefore, the goal of Lean and Agile is to reduce cycle times to a minimum.

    WIP limits prevent them team from taking on too much work and reveal the bottlenecks. Teams get their work done faster by limiting the amount of Work-in-Progress.

    The relationship between WIP and cycle time is expressed by the following equation

    Work-in-progress (WIP) = Lead Time * Throughput

    The Lead time for a process is equal to the number of jobs to be executed divided by the average time to execute each job

  • Kanban board

    5. Kanban board

    Kanban boards are sign boards. Kanban (Japanese – "cards you can see") is a pull system where resources prevent work from piling up in a constrained process so that the lead time to deliver value to the business is not compromised. Work in the Kanban board moves from left to right and only limited number of items can be in each stage of the project. Teams are disciplined and committed to working within their specified Work-in-Progress (WIP) limits to ensure optimal flow in the system.

  • Cycle Time and Lead time

    6. Cycle Time and Lead time

    The lead time indicates how long it takes for a work item to go through the entire process. Cycle time is a subset of lead time. Cycle time is the time it takes for a work item to go through part of the process (e.g., In Progress to Done status, from the coding phase to the testing phase, Complete a task).

    There are several strategies for lead time and cycle time problems, such as increasing system's efficiency, increasing capacity (crashing), and stop taking requirements (not always possible).

  • Cumulative Flow Diagram (CFD)

    7. Cumulative Flow Diagram (CFD)

    Cumulative Flow Diagram (CFD) is a tool to track the performance of the workflow. CFD visualizes the relation between Work-in-Progress (WIP) and lead time. Teams can use CFD to easily identify bottlenecks.

  • Throughput

    8. Throughput

    Throughput is the number of items a system can deliver in a given time frame. A system with high throughput can be expected to be more responsive to customer needs.

    Throughput is equal to WIP divided by cycle time.

  • Takt Time

    9. Takt Time

    Takt time is defined as the speed at which a team should put software into production to meet customer requirements.
    The takt time (German – Taktzeit) enables to measure the current productivity of the delivery process in relation to customer demand.

    Takt time = available time for production / units required (customer demand)

    Tackt time can be compared to cycle time, enabling the team to identify non-value-added activities and achieve a continuous flow of value to the customer.

  • Quality – passed test cases

    10. Quality – passed test cases

    Acceptance tests are written before new products are developed (on the back of the story cards). They ensure that the code meets the requirements. For software, the initial tests will fail because the code is not yet fully developed. If the code is written correctly, it will pass the tests.
    The higher the success rate in the tests, the greater the probability that there will be no failure in production.

  • Escaped Defects rate

    11. Escaped Defects rate

    Escaped defects are the defects that slipped by the testing team. The defect rate measures how often defects are found. Escaped defects are the most expensive to fix. An increase in escaped defects signals that a process is flawed.

  • Team Velocity

    12. Team Velocity

    Velocity is a measure of how much work (sum of the story points of done stories) a team can get done per iteration.
    Velocity is helpful to predict how much work can be done in future iterations. Velocity changes and should be measured at the end of each iteration. It is worth noting that the velocity of teams cannot be compared as the sizing and estimation in each team varies from others.

    Computing the initial velocity faces the "Cold start" issue, and can be done as follows: • based on historical data of previous similar projects, • running a few iterations and then calculate the velocity, • or based on expert judgment.