My Ideal Agile Delivery Report

One of the biggest challenges, but also one of the most beneficial things a team can do, is shift from traditional style status reporting to a more agile approach which is focused on transparency and action-ability.

Too often, I see status reports that are multi page affairs whose main job appear to be to distract you from the information that really matters and provide the veneer of a well-managed project. They are filled with window dressing aimed to lull you into a false sense of security around how a team is going irrespective of the reality.

Quite often you will see a status reported of “Green — All proceeding well” even though if you were to ask anyone on the team how they thought they were going, they would tell you they were heading for a train wreck.

Most traditional reports that I have seen provide a raft of vanity metrics that help stakeholders feel good about where we are spending money and are not designed for action-ability. An ideal agile report focuses purely on potentially actionable information because everything else is waste.

With that in mind, I’d like to outline my ideal agile delivery report.

My ideal agile delivery report is both short (for ease of completion and consumption) as well as highly actionable. It consists of only 6 key pieces of data with very clear reasons as to why they exist.

Other reportable information should only ever be added if there is a definitive reason as to why it should be included, but also what types of decisions it will enable.

If you can’t act on a piece of information, there is no point reporting on it at all.

My Ideal Agile Delivery Report

These 6 factors drive specific actionable discussions around what I would argue are the most important factors of a team.

6 Key Reporting Elements

A Release Burnup chart

A Control chart

A Team Health check

Risks and Strategies

A Budget Forecast

Support & Incident metrics

Why are these 6 factors so important?

The Release Burnup chart

By far the most powerful piece of information a team can provide, this report provides real transparency on when a team really believes they will end. It provides clarity on both the scope of work a team thinks they need to deliver to achieve an outcome, but also the speed at which they can do so.

Because it provides clarity on these two factors independently it enables stakeholders and product owners/managers to focus on ruthless prioritisation of scope to maximise the impact they make in the time frame they need to, while also enabling team members to focus on how to get faster over time by eliminating wasteful activities and systematic change of how they work.

The Control chart

A control chart is the most utilised and misunderstood charts within the teams I’ve worked with. It is often overlooked and goes unused.

When used correctly however it is a key factor in establish a simple but resilient learning flow. By charting the cycle time of all work, and then focusing on the items that are the biggest outliers, a team begins to talk about the items that are the biggest impediments to flow. Over time discussing and resolving these factors not only speeds a team up, but it also increases the accuracy of the information a release burnup provides.

Risks and Strategies

Unlike traditional Risks, Assumptions, Issues, Dependencies (RAID) logs, alignment on Risks, and the Strategies that will be used to address them increases the ability for teams to take action as things change. By aligning on the strategies a team will use rather than the specific mitigation plans they will put in place, a team is able to better respond to unexpected eventualities.

This generally forces a shift from a passive risk management approach via RAID logs into an active risk management approach via increased alignment, ownership and autonomy of a team.

Budget Forecasts

Budget forecasts are critical for product teams. Due to the traditional split of build and run elements of most IT organisations, teams often ignore the importance of cash flow within the business. At its worst sometimes it feels like money grows on trees and budgets are an unnecessary hardship rather than a critical factor in building a successful business.

Forcing teams to both project and track budget enables team to begin to focus on managing a product team like a business. Based on a given budget, teams are expected to worry about the cash flow of their team and the deferring of investment spends to remain within budget (“profitable”). What this looks like for most teams, is that the discretionary level of investment spend allocated to a team allows them to consider what key investments they should make above and beyond the burn rate of their stable team.

The sheer scarcity of funding forces clear budget management within a team.

Support and Incident metrics

Clear information about open support and incident tickets, and their rate of resolution is the last piece of critical information a team needs. This information enables a team to understand the current supportability of their product. This in turn enables them to focus on balancing their efforts between building things for the future and making sure their product works for today.