One specific aspect of the Agile methodologies for project management, which transformed the way we measure work impact on a given project is by introducing and implementing the Agile metrics. Learn more.
For nearly a decade, agile project management methodologies have been widely embraced initially by software teams. These days, the agile philosophy for project management has been successfully implemented in possibly any type of organization and team structure, increasing a team’s ability to respond to market trends, work speed, and collaboration.
Agile, as an iterative approach to managing the development of a different type of projects, brings into focus the importance of continuous releases, while with every iteration you can easily incorporate customer feedback.
One specific aspect of the Agile methodologies for project management, which transformed the way we measure work impact on a given project is by introducing and implementing the Agile metrics.
Many traditional project management KPI’s can provoke teams to take wrong actions in project management on all levels. For example:
Quality is measured by the number of documented requirements followed, instead of measuring if a quality outcome was achieved.
Productivity and progress are measured only by delivering an “error” free project or product, instead of measuring planned hours vs. time spent on delivering the “error” free project/product.
Performance is measured by how fast you can deliver, even if these are the wrong things to deliver, sacrificing quality, instead of measuring on-time completion percentage without sacrificing quality.
Measuring metrics, defined by the traditional project management approach, won’t help teams to finish projects faster, but only amplify the pressure.
With the vast adoption of agile project management, new, agile metrics have emerged. Agile metrics are meant to help you better analyze and understand your workflow, discover flaws, and improve so your team could focus on satisfying customers (clients) through the continuous delivery of the valuable product (project).
First, let’s introduce six important, but yet very simple principles of the Agile metrics, so you can have an adequate understanding of the overall context and purpose of these metrics.
This means that the team should collect the metrics, share, and use them within the context of their work. For example, you are part of the marketing team in your organization and you have collected metrics for your website traffic.
However, instead of your team analyzing these metrics, you give them to the human resources to extract the essence. Will they be able to decrypt the metrics better that your team? Most certainly they won’t. The reason is outlined in agile principle number two.
This is as simple as it sounds. Numbers should tell a story. If you are collecting metrics and you cannot explain how you have collected them, when, where, and why then these numbers will have no added value to the project.
Always try to answer these two questions:
When you get these numbers, what you plan on doing with them?
What actions do you derive out of these metrics?
If you can’t answer clearly both questions, then most probably there isn’t a story behind those numbers and it’s pointless to collect them.
Accepting that each metric we collect tells a certain story, used in the right context, it can be used as part of a specific experiment (or problem investigation) – how can we improve these metrics and what are the possible outcomes if we succeed (is it worth it?).
There is no value in collecting metrics if your team can’t extract the essence, which you can use to improve product, project, or customer satisfaction level. Often organizations will collect many irrelevant metrics which are completely unusable towards problem investigation or proving a hypothesis.
By not focusing on a few, important metrics, you may get overburdened and completely stop paying attention to all these metrics you are collecting. However, only what can be measured, can be improved as with time you will have a solid historical set of data with which you can iterate and improve.
10 Years Kanban Experience In 1 Free Book:
Very often we will collect many metrics which are good to have, but we don’t always know when exactly we will have to pull out and use them. The danger zone of collecting many metrics is that you can quickly get distracted from analyzing those metrics which matter the most for the current goal in your organization.
For example, your target goal for the current month is to have 100 new signups for your product. Looking at the traffic coming to your website, you know that most of the signups come from a popular topic your team has written about.
However, you see a slight increase in signups from another topic which has a room for improvements. You get excited, and you decide with your team to focus on writing articles for the new trend instead of pushing further what’s already working by optimizing it.
Our work on the new trend we’ve noticed may reap success for the 2-3 months to follow, however, for our current goal, acquiring 100 new signups will most probably not work*. It will be more efforts-efficient if we are improving what’s already working.
So it’s essential to keep your brain above the water and focus on the metrics which will deliver success for your current goal, no matter how close or distant the goal is.
*Note: To clarify the example, in SEO and acquiring organic traffic, it takes at least 3 to 6 months for a newly produced content to rank and gain traction.
As we aim to achieve high productivity and efficiency, metrics should be collected through automation.
However, before taking the extra time to build your own automation tool or throwing money at expensive solutions, it’s best to collect a small (but relevant) set of metrics manually.
Why? Because by doing things yourself, you and your team will clearly understand where does the data for the metrics come from, what’s the most accurate approach to collect and measure metrics, etc. Also, this is a great approach to creating a highly collaborative culture with the team.
Of course, once your team understand the input data and learn how to translate metrics into a story, you may proceed to automate the system.
A team should not emphasize collecting just a single metric. For example, there are no benefits to collecting only the number of completed tasks if you don’t collect how much time your team has spent on them, or even better, what value has been generated completing these tasks.
Instead, a team should focus on collecting metrics which correlate to a problem you are trying to fix.
Now, let’s take a look at the most important agile metrics a team should measure and put them into the right context.
And Optimize Your Workflow.
Work item age (aging work in progress) is the amount of time passed between a work task has started, and the current time of the task. Work item age is a relevant leading indicator only for non-finished work items. It compliments the cycle time, which is a metric, only appropriate for finished work items.
The work item age metric has mainly two uses – first, indicates how your current tasks are moving forward and second, gives you a clear idea of how you were performing in similar contexts in the past.
Along with measuring aging work in progress, we would like to measure our flow health. One important thing to visualize is the age of the cards that didn’t move recently. Also, you can combine the overall age with where currently the work is plus what the team expects their cycle time to be.
Combining all these metrics can help the team to focus on the tasks that are most critical of missing the team’s expectations. The aging work in progress is visualized through a very powerful measurement tool called aging work in progress chart.
Two of the most important agile metrics in Kanban are lead time and cycle time. Both can help you understand how much time work items spend in tour workflow until they are completed.
Often, the two metrics are confused, however, there is a clear differentiation between them.
Lead time measures the total time a task spends from the moment the task is requested to the time it is delivered. It measures duration from beginning to end, including the time the task needs to be processed and the time it spends sitting in a queue.
Cycle time measures how much time it takes a task to get from point A to point B, it’s the time you actively spend working on a card. As cycle time starts from the commitment point, it helps you understand the time you will need to complete a particular task.
The average cycle time and lead time can be measured through the use of a Cumulative Flow Diagram.
Both metrics can raise a red flag when items across your entire workflow are not moving forward.
Throughput measures the average number of tasks processed per time unit. In a Kanban system “the number of tasks processed per time unit” could be translated as “processed cards per day,” “cards per week,” or “story points per iteration.”
Throughput is a productivity agile metric which represents the productivity level of your team in the past. By measuring throughput you can better understand the impact your workflow has on the overall business performance.
One caveat here is that throughput shows the number of tasks completed per day, but it doesn’t show you exactly when the tasks were started. As we mentioned in principle #6, a single metric has minimal use on its own. Combining throughput metrics with cycle time and lead time will result in much more precise metrics for future decisions.
Through the help of the Throughput Histogram, you can measure throughput which will give you a better overview of your team’s capacity.
Work in progress (WIP) is the total number of work you have committed to but have not finished them. Practically speaking, unfinished work cannot add value to the team, customer, or organization. Work in progress can be easily monitored on a Kanban board.
Visualizing work on a Kanban board has a great advantage when you want to receive important information on all tasks that are in progress and supplemental information for each card such as description, assignee, deadline, to-dos, and so on.
Thus, it is very important to clearly define what is the WIP limit for a given workflow and regularly measuring it through the help of the Aging Work in Progress chart. With the help of Aging Work in Progress chart, you can easily see the total number of all cards that are in progress and the time passed since they were started. This will indicate if there are tasks which have been in progress for too long and inspect why.
Learn more about Agile tasks breakdown
In a Kanban system, work that cannot be moved forward in the workflow is visualized through a “blocker” sticker. A blocked card is different from work in the queue, which waits to be pulled and moved to the right on the board. A blocked card usually means that it waits on external dependency or there is another major reason which blocks the assignee to proceed with the work on that piece of work.
Blocked card signals that work in progress needs immediate attention and blocked time is a valuable agile flow metric.
To measure the number of blockers you have on the board, count how many cards are blocked and for how long those cards stay blocked. By measuring blockers you would like to find ways to improve a team’s flow by reducing both blocked items and blocked time, thus improve efficiency.
Cumulative flow diagram (CFD) is not a metric, however, it is one of the best agile tools to measure:
These are all agile metrics, which we have already discussed above.
CDF is the graphical representation of your WIP flow in a Kanban system. With the help of this metric, you can understand the state of your work in progress and what can be done to speed up the workflow.
What you will see on a CFD are color blocks which represent the swimlanes on your board, and the width of the swimlanes represents the number of cards in it.
The cumulative flow diagram can be used to provide clear visual signals of where process bottlenecks may be forming and then ask why they have formed and how we can improve this workflow.
Metrics are a good starting point to gain quantitative insight into your team’s performance. They also provide goals for your team which can be more easily measured. Metrics are important, but you should not get obsessed over them, especially by collecting too many unnecessary metrics. Keep it simple and agile, use both qualitative and quantitative feedback to drive change.
And Optimize Your Workflow.
In Summary
Agile metrics will help you analyze and understand your workflow, discover flaws, and improve, so your team could focus:
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.
