0

I was hoping for any good examples of how anyone has effectively presented RAID logs (or the individual lists of Risks/Assumptions/Issues/Dependencies) in their projects. In particular for Agile/Scrum projects.

I look after a team of PMs and have recently been looking at how we can better manage RAID. There's a well established method of using a spreadsheet such as this RAID Log example from Project Smart, however I was wondering if any other ways have been used/proven to be effective in the past?

We use Jira and there are a couple of extensions available that basically use a new issue type to track the risks. Also having a highly visible Risk Matrix and Dependency Mapping board I have found useful in the past. I'm ideally looking for creative ways of getting high visibility and participation.

Thanks,

Dave

Improve this question
3
  • 1
    For scrum this doesn't make a lot of sense, as these items are all Product Backlog Items and are ordered by the Product owner with the scrum Team and other interested people.
    – jessehouwing
    Jul 26, 2019 at 12:45
  • 1
    Maintaining separate logs, each with their own order makes it hard for the people involved ti track the overall position of each item type with relation to the others. Remember that in Scrum there is no requirement to have User stories only, you can put Risks, Assumptions and other items on the Product backlog.
    – jessehouwing
    Jul 26, 2019 at 12:48
  • more than a format, in our teams we typically discuss the RAID log items specially the D in RAID logs in our daily stand up to make sure there is no blockers to the task to be completed in the sprint. As a SM I highlight the items in RAID logs with higher impact on sprint objectives to the team and let the team work out the possible ways to deal with those. This way the RAID Logs sheet is "live" document with team is aware of any burning item that they need to focus upon.
    – Ashutosh Deshmukh
    Jul 28, 2019 at 16:25

1 Answer 1

Reset to default
1

RAID logs are not usually maintained when working with Scrum. The reasons for this include:

  • We release frequently, which often reduces risk
  • Frequent releases also reduce the need for assumptions
  • Agile favours individuals and interactions over process and so we prefer to regularly discuss things rather than to rely on documentation
  • The Scrum retrospective is designed to address issues
  • The close relationship between the development team and the Product Owner reduces the need for separate external reporting

In fact one of the arguments for moving to Scrum from a traditional development approach is that it helps to eliminate processes like maintaining RAID logs.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.