Key Takeaways
- A RAG status is fast to read, but most teams never write down what each color means, so amber means something different to everyone in the room.
- The first RAG status of a release inherits the team’s confidence vote. Like the vote, it is a snapshot taken on planning day.
- Give each color a definition in days against the committed date: green on or after the 85% forecast date, amber between 50% and 85%, red before 50%.
- Amber with a number is the moment to renegotiate scope, dependencies or capacity, while there is still slack to trade.
It is Thursday, the steering review starts at ten, and the release is amber. Last week it was green. Nobody can point to the one thing that changed, only that it “feels tighter now”. Then someone asks the obvious question: does amber mean two days late or two weeks late? The room goes quiet, because nobody ever wrote that down.
What a RAG status is, and what it leaves out
A RAG status is a traffic-light summary of project or release health: red, amber or green. Its strength is speed. An executive can scan twenty releases in a minute. Its weakness is that the threshold behind each color is rarely defined. Ask ten people what amber means and you will hear “a risk we are watching”, “we might slip” and “we have slipped but we have a plan”.
The color is usually set by the person closest to the work, and that person is usually right. A RAG call is expert judgment from people who know the code, the people and the backlog. The problem is not the judgment. It is that the color has no unit and no refresh: it is chosen at one checkpoint and stays on the slide until the next.
The vote was a snapshot. So is the color.
At PI planning or release commitment, the team votes its confidence in a committed date. That vote is expert engineering judgment on the scope, dependencies and capacity known that day. The first RAG status inherits it, and it is green.
Then the weeks after the vote happen. Scope gets added. A dependency surfaces late. Someone is pulled onto an incident. These are the three things that erode a committed release date, and none of them waits for the next status meeting. The color stays green while the forecast behind it moves, which is how a release ends up as a case of watermelon reporting: green outside, red inside.
Give each color a definition in days
The fix is not another meeting. It is one definition the whole room shares, written against the committed date and the confidence level the team voted at. When the date is forecast as a committed date with a 50/85/95% confidence band, the colors define themselves:
- Green: the committed date is on or after the 85% forecast date.
- Amber: the committed date sits between the 50% and 85% forecast dates.
- Red: the committed date is before the 50% forecast date.
Then add the number. “Amber: the 85% date is now six days past the committed date” answers the question the room could not.
An illustration: a release is committed for 14 November at 85% confidence. In week three the 85% forecast date is 12 November, so the release is green with two days to spare. In week five, nine items have joined the Fix Version and a platform dependency has moved. The 85% date is now 20 November and the 50% date is 11 November. The committed date sits between them, so the release is amber, six days short of its 85% line. Of the eight days the 85% date moved, five came from scope added after the vote and three from the dependency.
Amber is the moment to renegotiate
An amber with a number attached is not a reason to worry. It is a prompt to act while there is still slack to trade. The team has three levers: move items across the MoSCoW cut-line, resequence the dependency on the critical path, or adjust capacity. Red, a committed date before the 50% line, is a full re-plan, with the same weight as a PI boundary.
The team still owns every assumption behind the colors: which throughput window to trust, whose capacity is in, what is in scope, and which links are real blockers. A defined RAG status keeps that judgment visible instead of buried in a status report that repeats last week’s date.
How Advanced Release Planning keeps the color live
Advanced Release Planning for Jira forecasts the committed date with a Monte Carlo simulation over the team’s actual Jira throughput and carries it with a 50/85/95% band. Release status is derived from where the committed date sits on that band, using the rule above, so nobody has to set the color. It changes when Jira changes: an item added to the Fix Version, a hard-linked blocker moving, a change in team availability. The movement since the vote is reported in days and attributed to scope, dependencies or capacity. The RAG status reference doc sets out the rule and what the app does not do.
Keep the RAG status. Executives read colors fast, and that is worth something. Just make each color mean a number of days against the date the team committed to, and let it change on the day the data does.
FAQ
What does RAG status mean?
RAG stands for red, amber, green. It is a traffic-light rating of project or release health: green is on track, amber needs attention, red needs escalation or a recovery plan.
What is RAG status in Agile?
In Agile release planning, a RAG status is most useful when it is tied to the committed date and the confidence level the team voted at, so each color maps to a position on the forecast rather than a feeling.
How should amber be defined?
One workable definition: amber when the committed date falls between the 50% and 85% forecast dates, reported with the gap in days to the 85% line.
See your committed date and its live confidence band in Advanced Release Planning, or install it from the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.