The Most Overlooked Agile Practice: RAID Log Explained

In fast-moving Agile projects, teams tend to prioritize delivering working software and maintaining clear communication over producing extensive documentation. Still, even highly flexible teams inevitably run into risks and challenges that can slow down progress if not addressed early. When there is no clear visibility into these risks, the result is often unexpected delays, disrupted roadmaps, and dissatisfied stakeholders. This is where a RAID log becomes a highly useful practice. Simple to set up yet very effective, it offers a central place to capture and manage the uncertainties and blockers that determine whether a project succeeds or stalls.

What is a RAID log? (Risks, Assumptions, Issues, Dependencies)

A RAID log is a project management practice, typically documented, that compiles four key categories of project concerns in one place: Risks, Assumptions, Issues, and Dependencies [1]. It is usually created early in the project (often during planning) and then updated continuously throughout the project lifecycle. At its core, the RAID log is a structured record of a RAID analysis, turning insights about possible project obstacles into an organized reference point for decision-making and follow-up.

Figure 1: Example of RAID log

Colorful RAID log diagram with four quadrants: Risks (Risk one, Risk two, Risk three) with “Track” and “Threat”; Issues (Issue one to Issue four) with “Manage” and “Threat”; Assumptions (Assumption one to five) with “Track” and “Reliance”; and Dependencies (Dependency one to three) with “Manage” and “Reliance”

Below is a brief look at each RAID element.

Risks are potential problems or uncertain events that might negatively (or positively) impact the project if they occur. For example, a risk might be “Key team member might leave mid-project” or “New technology may not scale as expected.” Teams should assess each risk (likelihood and impact) and plan mitigation or contingency actions in advance. A RAID log’s risk section is like a risk register, listing each risk along with details such as its trigger, probability, impact severity, owner and mitigation strategy [2].

Assumptions are things the team is assuming to be true for the project to proceed, in the absence of absolute proof. For example, an assumption might be “We assume the API from the vendor will be available by Q3” or “We assume users have basic training on the current system.” Documenting assumptions is crucial because if any turn out to be false, they can become new risks or issues. In some methodologies, “A” can also stand for Actions (that is, action items or to-dos), but in Agile projects it is often the key assumptions that most urgently need tracking. Tracking assumptions in the RAID log helps prevent scope creep and misunderstandings by making implicit expectations explicit [3, 4].

Issues are events or problems that have already occurred and require resolution. In other words, an issue is a realized risk or an unanticipated problem that is impacting the project right now. Examples include “Build server is down” or “Team member X is out sick during the sprint, causing a capacity shortfall.” The issues section of the RAID log should record each issue with a description, the date identified, an owner responsible for resolving it, its status or resolution, and any next steps. Documenting issues and their resolutions helps the team learn from them and avoid repeats in future projects [2].

Dependencies are project work elements that rely on something (a task, delivery, or decision) outside the team’s direct control or outside the current scope. Dependencies can be internal (for example, one team’s work depends on another team’s deliverable) or external (for example, waiting on a vendor or regulatory approval) [2]. “Feature A cannot start until Platform Team delivers the authentication module” is a typical dependency. In Agile, dependencies are especially important to track because they can block user stories or sprints if not managed. In the RAID log, dependencies should capture what is needed, from whom, by when and the impact if it is delayed.

Some teams use “D” to mean Decisions instead (or in addition), logging key project decisions and their rationales. Many RAID logs therefore incorporate both Dependencies and Decisions for completeness, sometimes expanding the acronym to RAAIDD [5].

Agile teams move fast, but that speed comes with risks. A RAID log gives you a single place to track risks, assumptions, issues and dependencies so you can spot problems early and keep delivery on track.

By compiling all four categories, a RAID log provides a single repository of critical project knowledge. It saves teams from combing through endless emails or meeting minutes to find that one crucial decision or assumption¹. Practice showed that this is one of the most immediate benefits, instead of searching in scattered channels, team members can instinctively check the RAID log whenever a stakeholder asks, “Who owns this dependency?” or “Why did we assume that?”. In short, the RAID log acts as a dashboard of project health, giving both the team and stakeholders a quick overview of what could go wrong, what is being assumed, what has already gone wrong and what external factors might influence delivery. Practitioners note that this visibility not only supports proactive risk management but also builds trust, since stakeholders see that nothing critical is left to chance.

How to structure and update a RAID log in Agile teams

Keeping a RAID log effective in an Agile environment requires more than simply filling out a template; it demands deliberate structuring and disciplined maintenance. The purpose of the log is to serve as a living tool that actively supports delivery, not a static document that ends up buried in a forgotten folder [6]. To achieve this, entries should be concise, clearly categorized, and directly relevant to the team’s current objectives. Just as importantly, the log should be reviewed and refreshed regularly, ideally as part of sprint ceremonies or project check-ins, so that emerging risks and dependencies are captured in real time.

An effective RAID log is also a shared responsibility. While the project manager often drives its upkeep, true value comes from collaboration with the project coordinator, PMO officer, product owner, and relevant stakeholders. By engaging these roles, the log reflects a collective view of the project landscape rather than a single perspective. This collaborative approach ensures that the RAID log remains practical, transparent, and actionable.

Structure and Format

A RAID log can be as simple as a table or as integrated as a dedicated software tool. Many teams start with a basic spreadsheet or table divided into four sections (or four tabs), one each for Risks, Assumptions, Issues and Dependencies. The University of Waterloo’s PMO [7] suggests including specific fields per category, such as triggers, probability, impact, and mitigation for each Risk; owners and due dates for Action items (if using Actions, or for each dependency), clear descriptions and resolutions for Issues; and dates and decision-makers for Decisions. The key is to capture enough information to manage each item without overloading the log with unnecessary detail.

Regular updates to the RAID log are critical. A RAID log derives its true value from how accurately it represents the current state of a project. When it is left outdated, it can mislead stakeholders, foster misplaced confidence, or even generate more confusion than if no log were kept at all. To prevent this, Agile teams are well advised to embed regular RAID log reviews into their working practices.

Figure 2: Best practices for RAID log maintenance

Best practices for RAID log maintenance shown as eight labeled pills: 1) Regular review schedule, 2) Assign ownership, 3) Capture changes promptly, 4) Document clear action plans, 5) Communicate updates, 6) Prioritize entries, 7) Review historical data, 8) Use automated tools.

Figure 2 summarizes the core principles [8] that ensure a RAID log remains a reliable and practical tool throughout the project lifecycle. Regular reviews at key checkpoints, combined with clearly assigned ownership, safeguard accuracy and timeliness. Updates are captured as soon as they arise, with action plans documented in detail to provide accountability and traceability. Communicating changes keeps stakeholders aligned, while prioritization ensures the team’s attention is focused where it matters most. Reviewing historical data allows lessons learned to inform future projects, and the use of automated tools enhances efficiency, collaboration, and consistency. Taken together, these practices transform the RAID log from a static document into a dynamic instrument for proactive project management.

Using RAID logs within Scrum

The Scrum framework offers a useful illustration of how RAID logs can be regularly updated, though the same practice is equally applicable in other Agile environments such as Kanban, SAFe, LeSS, or Disciplined Agile [9, 10, 11]:

During Sprint Planning, review the RAID log for any risks or dependencies that might affect the upcoming sprint. Add new items identified in planning, such as assumptions made in sprint goals or new external dependencies for planned stories
In Daily Scrums, if an impediment (blocker or issue) arises that is not resolved immediately, someone (often the Scrum Master, but developers and the Product Owner can also intervene) can log it in the Issues section of the RAID log, ensuring it is tracked to resolution beyond that day’s stand-up
During Backlog Refinement, when looking ahead to future work, note any new risks or dependencies that come up and add them to the log. For example, “If we pull in Story X next sprint, it has a dependency on vendor Y’s API, add that to RAID now so we remember to coordinate it.
At the Sprint Review, update the log with any new assumptions or decisions made about product direction. If stakeholders introduce a new risk, such as a market change or regulatory concern, capture it
During the Sprint Retrospective, the team might review significant issues that occurred and ensure they are documented in the RAID log (if not already) along with lessons learned or follow-up actions. The retrospective can also be a chance to clean up the RAID log, closing items that are resolved and highlighting any that need escalated attention

Oliver Wyman’s research [12] on Agile in regulated industries describes teams explicitly moving each RAID item to a ROAM status by the meeting’s end (that is, deciding to Resolve it, Own it, Accept it, or Mitigate it) and carrying over unresolved items to the product backlog or risk register as appropriate.

In practice, an Agile team should structure the RAID log so that it is simple, clear, and up to date. It should be reviewed frequently, essentially becoming part of the team’s cadence. When used this way, the RAID log truly supports agility by enabling quick responses to risks and continuous alignment on issues and dependencies. As the University of Waterloo PMO emphasizes, the RAID log (or risk register) is a living document that should be reviewed regularly with the project team and governance, and updated with new information as the project evolves.

Conclusion: embedding discipline and transparency in delivery

In Agile software projects where change is rapid and uncertainty is a given, maintaining a RAID log is a smart insurance policy. It keeps the team’s collective eye on Risks that need watching, Assumptions that must hold true, Issues demanding resolution and Dependencies to manage proactively. It is important to note that RAID log does not contradict Agile principles, rather, it supports the Agile ethos of transparency, inspection, and adaptation (TIA) by ensuring that potential problems are visible and addressed continuously. By clearly defining each RAID element and regularly updating the log, Agile teams can avoid the trap of “risks and issues going to die” in forgotten documents. Instead, the RAID log becomes a living reference that evolves with the project, enabling the team to respond faster and stakeholders to stay informed.

Now that you’ve read this, maybe you would like to know more about how RACI Matrix & Milestone Tracking Improve Delivery & Accountability