Using RAG status in Agile projects

RAG (Red, Amber, Green) status reporting is often associated with traditional, plan-driven project management. As a result, I’ve sometimes seen it dismissed as incompatible with Agile ways of working.

In practice, that is rarely true. Plus, stakeholders love RAG reporting as a universal way to quickly understand what is going on. So Agile teams can’t escape using it! And shouldn’t try.

Agile teams still need to communicate progress, project status, risk and confidence to stakeholders. The difference is not whether you report RAG with your updates, but how you do it. This article explores how RAG status in Agile environments can work without undermining Agile principles or creating unnecessary overhead.

Why status reporting still matters in Agile

Do I even need to explain this? Agile teams focus on delivering value iteratively, responding to change, and maintaining a sustainable pace. None of that removes the need for visibility.

Stakeholders still want to know:

• Are we on track to deliver what we said we would?
• Are there risks we should be aware of?
• Do we need to intervene or make decisions?

RAG status, used thoughtfully, can provide a simple, shared language for answering those questions. The key is to integrate it into existing Agile events and artefacts, rather than bolting on a separate reporting layer.

Understanding RAG status in an Agile context

At its simplest, RAG status is a health indicator:

• Green: on track, no material concerns
• Amber/Yellow: at risk, attention or action required
• Red: off track, intervention needed

In traditional environments, RAG status is often applied to the whole project against a fixed baseline, or as an aggregate through different project components. For example, a leader might RAG project schedule, budget, scope and then aggregate that into a single RAG color for reporting.

Agile environments are different. Work is incremental, scope evolves, and progress is measured through delivery rather than adherence to an upfront plan.

This means color coding reports in Agile is usually:

• Time-bound (for example, sprint-level rather than whole-project)
• Outcome-focused (value delivered, not tasks completed)
• Dynamic, changing as new information emerges.

To be fair, even projects managed with linear methodologies often find that their RAG status is dynamic!

How to report RAG status in Scrum

Scrum already includes built-in opportunities for inspecting progress and adapting plans. RAG status can be layered into these without adding new ceremonies or additional bureaucracy.

Sprint planning and sprint reviews

During sprint planning, a simple RAG assessment can be used to test confidence in the sprint goal. For example:

• Green: confident the sprint goal is achievable
• Amber: risks identified that could affect delivery
• Red: sprint goal unrealistic without change.

The team can agree on this together, guided by the Scrum Master or project manager (if you have those roles).

Daily stand-ups

Daily stand-ups are not status meetings for management, but teams often find value in using informal RAG language internally.

For example, a team member might say they are “Amber today” due to a dependency or blocker. The focus should be on ‘back to Green actions’. What does the team or squad need to do so that the blocker is resolved? Build your recovery plan into what happens next.

Read next: How to get a project back to Green

RAG becomes a familiar shorthand for stakeholders without detailed Agile knowledge, and a way to articulate confidence – alongside your existing burndown charts and other tools.

How to use RAG status with Kanban

Kanban’s visual nature makes it particularly well suited to RAG-style indicators. Many Kanban software tools will let you add a custom field for status or progress, and you can color code digital sticky notes (and physical ones) to easily see what activities need attention.

Visualising RAG on Kanban boards

RAG can be applied at different levels on a Kanban board:

• Individual work items (for example, a blocked or at-risk ticket)
• Columns or stages (highlighting bottlenecks)
• Classes of service or workstreams.

Managing flow and bottlenecks

One of Kanban’s strengths is its focus on flow. RAG indicators can reinforce this by highlighting where work items have aged beyond expected thresholds. This is tedious to do by hand so set up automations to move the status on once the threshold is breached.

Supporting continuous delivery

Because Kanban operates in a continuous flow, RAG statuses for individual items should be reviewed regularly and updated in near real-time. This avoids the trap of stale status reports that no longer reflect reality, but it is more work for the person managing the ticket.

Benefits of using RAG status in Agile frameworks

I love RAG status reporting as it’s easy, universally understood (although make sure stakeholders do understand what the colors mean). It’s a huge value add for stakeholders and I’ve used it throughout my career.

It gives you:

Better visibility and transparency. RAG provides a quick, accessible snapshot for people who are not embedded in day-to-day delivery, without requiring detailed explanations of Agile metrics. I know you love velocity, but who outside the team really understands it?

Proactive risk management. Let’s normalize Amber and Red status as signals rather than failures. Teams are more likely to talk about issues early (when they are easier to address) than hide them if they aren’t ashamed to move the status to Red.

We’re communicating RAG status in agile teams and everyone knows what it means.

Practical tips for implementing RAG in Agile teams

If you want to introduce traffic light reporting into an Agile environment, a few principles will help it stick.

Start small and lightweight

Do not introduce new project reports or meetings purely for RAG. Do you really need a new project review meeting? I’m guessing no.

Agree what the colors mean

Definitions should be explicit and shared, and ideally aligned to other projects using non-Agile approaches and reporting RAG status.

Get your PMO definitions and use those – and if they really aren’t fit for purpose, have a good think about why so you can justify why an Amber adaptive project is not the same as an Amber linear or predictive project.

Focus on outcomes, not activity

Base RAG status on delivery confidence, risks and value, not on how busy people look! Software development keeps people busy – we know that already!

Schedule slippage might be one of the criteria that pushes your sprint into Amber, if you can’t hit all the story points you expected to.

Keep it honest

If everything is always Green, the status is meaningless. Psychological safety matters. I’ve talked about watermelon projects before – agile deliveries are not special in that respect.

Review and adapt

If progress reporting starts to feel bureaucratic or unhelpful, change it! You would for any other part of an agile methodology that wasn’t working. You can do it with this too. Chat about it in the agile retrospective and update the ways of working for next time.

Bringing it all together

RAG status and Agile are not opposites – at least, that’s what I think.

Agile provides the detail, learning loops and delivery rhythm. RAG provides a shared, high-level language for confidence and risk. Together, they can improve transparency, trust and decision-making for portfolio reporting.

What do you think?

This article first appeared on Rebel’s Guide to Project Management and can be read here: Using RAG status in Agile projects