Traditional and Agile are two contrasting project management approaches each with unique characteristics.
The Difference between Traditional and Agile Projects
In traditional project management – also called the Waterfall methodology, tasks are executed in phases in a linear, sequential way. Each phase must be completed before the next phase can begin and there’s no overlapping in the phases. Stakeholder and customer requirements are gathered at the beginning of the project, and then a sequential project plan is created to meet those requirements.
Given the nature of traditional project planning, there is a lot of emphasis on upfront estimation and planning of effort, times and costs – and then tracking the actual corresponding values. A (well) defined plan is used to provide the estimated project end date – and teams and stakeholders then try and stick to that date, as well as other project attributes such as cost. Invariably, traditional projects overrun their time and cost estimates – and that contributes to project failure!
Agile, on the other hand, is a nimble and iterative process that operates in a more flexible manner. A high-level project plan may be defined approximately. However, the detailed planning and execution happen in sprints (also referred to as iterations) where prioritized tasks (user stories) are completed within short intervals, typically around two weeks. These prioritized stories tend to be fluid, and are taken up based on the success of previous sprints and customer feedback, rather than having all tasks prioritized at the onset in the requirements phase.
At the end of each iteration, an updated, tested, potentially shippable version of the product is presented, and project stakeholders decide what the next iteration will target. The focus in Agile is to deliver a working piece of product every 2-3 week iteration – and keep doing these iterations until the project is deemed to be complete – which means all the critical and important requirements are completed. However, there is no overall project plan – or just a high level overall plan – there is just the Sprint plan. Hence the focus of project tracking and metrics is necessarily very different.
Moving from Traditional to Agile
In spite of the structured approach in traditional projects, they often failed due to a variety of reasons and Agile methods came up in response to those failures.
Transitioning to Agile, although beneficial, requires an understanding of how to effectively monitor their progress using agile metrics to measure the completion and quality of products or services, as well as track team performance and productivity. Using agile metrics to measure a team’s productivity is a key part of Agile’s philosophy. Metrics contribute to building a team’s culture. It provides quantitative insights into the team’s performance. Project managers can choose a wide range of metrics to depict different aspects of progress at the Sprint and Release levels of agile projects. This article will give you a deeper understanding of the variety of metrics for the agile methodology and will enable you to determine how and when to use them most effectively when communicating progress to project stakeholders.
Agile Project Metrics
When it comes to implementing and using Agile metrics, the two key methods – Kanban and Scrum – provide a range of metrics. Scrum and Kanban are two of the most widely used Agile frameworks that help in building better products and services. Scrum relies on a Sprint-based plan with some focus on Sprint-level estimation, planning and delivery every 2-3 weeks. The Kanban Method relies on visualization and continuous delivery and focuses on Lead Time, Throughput and the ability to forecast performance using statistical modeling.
As Agile teams increasingly adopt both Scrum and Kanban principles and practices, this article covers the key metrics from both to help you decide how you will monitor your agile projects.
Key Metrics used in Agile projects
- Sprint Burndown
Scrum teams organize their process into sprints and decide how much work they can complete in each sprint. A sprint burndown report keeps track of the work progress throughout each sprint. Sprint burndown chart is a graphical representation of tasks/outstanding work versus time. Time is plotted on the horizontal axis while tasks are plotted on the vertical axis.
The output is measured in terms of story points while effort spent within a sprint is tracked in terms of hours that helps in assessing performance against the planned sprint scope and hours. The sprint burndown chart helps teams see where they are and predict whether the sprint will be completed in time or not. It is useful in providing stakeholders with the status of sprint goals in an easy and understandable way.
- Release Burnup
Release burnup chart measures how many story points are in the product backlog versus how many are completed till date. Using a burnup chart, a team can easily track their progress as they work towards completion of a sprint.
Burnup charts are particularly useful when more work is required than was originally anticipated, or when a customer suddenly demands for extra features. The burnup chart will show the increase in scope, team velocity and actual progress made by the team. Moreover, it prevents disruptions to team workflow and makes estimations about the amount of work more accurate. Any changes made to the budget or the scope of work are clearly visible at the top of the chart and the team can adjust accordingly.
- Story Completion
Story completion is the number of stories completed in a sprint versus the number of stories that were committed. In simpler way, it is calculated as below
Story completion ratio = (Total no. of stories delivered/ Total no. of stories committed) * 100
So if a team puts ten stories into a sprint, and completes nine of them, they have a completion ratio of 90%. This is an effective metric to check the percentage of total number of stories delivered in a sprint against the committed ones. This can be used in retrospective meetings for discussing stories and identifying root causes of delayed delivery.
- Throughput or Velocity
Throughput or Velocity is one of the most crucial Agile performance metrics. Throughput measures stories or story points per iteration. It represents a team’s capacity per sprint. In a Kanban system, for example, as work is visualized in cards, throughput is measured based on how many Kanban cards were finished in a given period (weekly, monthly, etc.) Sprint Velocity in Scrum and Throughput in Kanban are very similar to each other and are often used interchangeably.
Since this metric gives you great details into your team’s real capabilities, you can better plan how much work you can deliver in a given period. Combining average throughput and cycle time can become the secret weapon for any team looking to improve their project delivery’s predictability. A Throughput Run Chart measures throughput of your team week-by-week where you can see how many work items you teams can complete, analyze their average throughput, and use that as an input for future planning activities.
The throughput/ velocity chart helps teams understand their sprint capacity or periodic (weekly/ monthly) capacity and helps them make commitments to their stakeholders on how much they can deliver within a specific time period.
- Cumulative Flow Diagram (CFD)
The cumulative flow diagram is one of the more advanced Kanban and Agile analytics charts. It shows how stable your flow is and helps you understand where you need to focus on making your process more predictable. It visualizes the flow of work through the various stages of a workflow on a continuous (cumulative) basis and helps teams understand how much work they have received and delivered, which workflow stages have shown to have bottlenecks and whether overall throughput is improving or declining.
This metric provides a clear visualization of workflow and understanding into how projects are progressing. Using the CFD, teams can figure out which stages of their workflow need improvement and forecast how much time it will take for them to deliver all the work in their backlog.
- Lead Time/ Cycle time
Lead Time or Cycle time measures how long a particular task takes. It measures how fast teams complete individual work items. When it comes to monitoring your team’s progress, tracking cycle times can be a great place to start. By looking at granular-level information regarding team members’ progress on their projects, the entire group gains valuable information about their work as a whole. This, in turn, shows how the team can improve its performance and offers an easy way to track success. Teams improve their ability to pivot to consumer needs and provide them with trusted products.
Lead Time is a key metric for measuring “Time to Market” and a key improvement goal for Agile teams is to reduce overall Lead Time for delivering work.
There are several variations of the Lead Time metric, including Average Lead Time trend, Lead Time Control Chart as well as Lead Time Distribution. Using these charts, teams can decide what their current performance is, where they can improve, and what delivery forecast they can commit with a specific confidence level.
- Flow Efficiency
Another very important metric that a Kanban system provides is flow efficiency. It shows you how efficiently your team can process work from start to finish. Flow Efficiency is the ratio of value-added (or Work Time) time by your overall lead time, which includes stages where no active work is done (Wait time or Blocked Time). This Flow metric works perfectly in a Kanban system where you can visualize both active and non-active stages in your process.
Flow Efficiency = Total Work Time/ Total Lead Time (Work Time + Wait Time + Blocked Time)
Most workflow systems/ processes have a lot of Wait time built in – such as time between handoffs from one stage to the next, waiting for customer review or approval, etc. and even the best of teams don’t get more than 15-25% Flow Efficiency! So, to improve Flow Efficiency, it is better to try and reduce Wait Times and Blocked Times rather than increase Work Time.
Takeaways
There’s a wonderful quote by Albert Einstein, “Not everything that counts can be counted and not everything that can be counted, counts.” Evidently, everything that has value can’t be measured and not everything measured in numbers has value. What matters is how you apply these numbers in order to boost the efficiency of the project. Agile metrics will help you analyze and understand your workflow, discover flaws, and improve, so your team can focus on satisfying customers and continuous delivery of value.
Ready to supercharge your Agile project tracking? Discover how Nimble Agile empowers teams to streamline progress monitoring, enhance collaboration, and achieve project success with ease. Try Nimble Agile today and revolutionize your Agile project management experience! Sign up now for a free trial of Nimble.
