The benefits of tracking data for Agile delivery
Firstly, delivery data can be the gateway to improving a team’s ability to accurately plan and forecast.
By understanding the volume of work a team is capable of delivering within a given time frame, product and delivery roles can - to a reasonable degree of confidence - predict that the same team, in the same environment, will be able to deliver that same amount of work again in the same time frame..
The more data a team has, and the greater consistency with which they deliver work, the more accurate these predictions can be. If planning isn’t based on some degree of quantitative understanding of how their team has historically performed, their forecasts and plans are educated guess-work..
Continuing to monitor data at a team level provides the opportunity for course correction in a timely manner. Teams can feed in real-life events that affect productivity - including dependencies and extenuating circumstances such as major incidents - to adapt the plan..
The second benefit to tracking project delivery data is that it can drive a culture of continuous improvement..
Assessing a team’s productivity enables them to scrutinise the environment they are working within at every stage of the process. Teams can identify and assess where bottlenecks and blockages arise, and what behaviours and processes in their working environment are preventing them from performing optimally..
Data is at its most powerful when it can surface the challenges faced by the team, driving them to create tangible change. When it supports developers, designers, testers and product owners to identify and remove bottlenecks and elements of their processes that are not fit-for-purpose, it is a force for good.
Different methods to track delivery data
There are many ways to skin the proverbial data cat, and each can be used to generate different conversations and outcomes within teams. A few are highlighted below, with their advantages and disadvantages, and an idea of how to know your data looks good.
Throughput: the amount of work that passes through a system in a given time frame.
- Standard measurement: number of stories;
- What good looks like: a team’s throughput is likely to steadily grow while they’re forming, and should become more consistent and predictable over time. More stories moving through to done indicates they are being broken down into their smallest testable chunks, with value continuously being added into the product;
- Best thing about it: considering throughput on a week-by-week basis can help teams pinpoint where delivery has been positively or adversely affected. This could be for a multitude of reasons - technical dependencies, blockages within the process, or tickets being too large. Analysing throughput helps teams surface these discussions such that they can put steps in place to resolve them;
- The biggest drawback: volume of tickets alone completed doesn’t serve to explain the root-cause of any issue. A common cause of low throughput is often pointed towards the core of a process, where stories are developed and tested, whereas often the issue lies at the input to a process - the volume and quality of stories ready to develop - and this can easily be overlooked.
Cycle time: the amount of time it takes for any given unit of work to pass through a process.
- Standard measurement: number of days;
- What good looks like: a consistent cycle time, such that more predictable delivery planning can be conducted; and one that is small such that new features are regularly being released, tested in a live environment, and yielding feedback to further improve a product;;
- Best thing about it: it is a powerful metric to drive continuous improvement, as it indicated when there are bottlenecks within a process that increase the duration of time taken to release a feature and receive feedback on it;;
- The biggest drawback: cycle time is ordinarily only collected on completed work. Any work currently in progress at the point of recording is not considered, and could well be blocked, which assessing cycle time would not identify. ;
Velocity: the amount of value a team delivers within a given time frame.
- Standard measurement: number of story points;
- What good looks like: a team that is able to consistently and accurately estimate the number of stories it will deliver in a given time frame, including the expected value and complexity of those stories;
- Best thing about it: by pre-defining to deliver a volume of features before work begins, teams are well placed to be equally committed to a scope of work and their time can be protected to deliver it within the given time period;
- The biggest drawback: velocity primarily supports teams working to a methodology that time-boxes its work. The velocity those teams expect to work at is predicated by the previous time-box, and invariably no two weeks in any software development team will be wholly similar - teams, personnel and dependencies all change, affecting the lay of the land.
Using metrics for an agile delivery team
Each of the above have their advantages and shortcomings. Which provides the greatest benefit to any project is dependent on how that team operates, and should be chosen and interpreted based on that environment.
One driving factor to picking your metrics will be the methodology you’re working within, which we talk more about in this Agile 101.
Measuring velocity primarily helps teams working in a Scrum methodology, as it clearly considers the amount of work to be done in a pre-established time period.
Throughput and cycle time have wider uses. While they support accuracy of forecasting, they also play a role in driving continuous improvement - which sits at the heart of projects being delivered in Kanban.
This article is the first in a three-part series on how agile teams can make use of delivery data. Future articles will provide more in depth considerations of the benefits laid in out in the early stages of this piece: forecasting with historical data, and how using data can enable a team to continuously improve.
