This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
@Scott. Perfect, thanks.
@Aldo - Good catch. Testing should be a separate option, IMHO.
@Valentin - Good points.
Identify Risks, Qualitative analysis - yes, for high magnitude risks the number could be irrelevant. Sometimes, for example, a risk could be blocker or will not be blocker only in some hypotheses. In such cases, the Qualitative analysis shall explain the consequences, hypotheses, when could become blocker etc.
Tracking risks - Yes, we can loose the trace of the risks in the life-cycle and we could need this Risk Backlog.
Anyway, the risk lists (no matter the form) should shape and drive our life-cycle. Looking beyond (release) life-cycle, we can have a "full work item list", with the future work in the product roadmap and also the current release.
Risks should drive both product roadmap and current life-cycle: we need a natural traceability between our risks lists and the roadmap/life-cycle ~ risks should be visible there via associated work (future/incoming/in progress). We need to have the value stream visible in the life-cycle - it is the same for risks (negative value).
Went though the "Explore Risks" part. Was wondering about Testing Risks. Will that be part of Quality risks? Or is that a missing option for "Explore Risks"?
If it is part of the Quality, then perhaps renaming it to "Quality and Testing Risks" else it could be a separate option?
I just updated the Identify Risks excerpt.
Wow! Great feedback. For the rest of the week my plan is to circle around and act on all the feedback we've received about the Inception goals the past few weeks. I'm starting here.
Renaming Identify Risks - Good point. I've always been unhappy about this decision point being named the same as the goal, but haven't heard a better solution until now!
Questions - Agreed, I've updated the description of the goal to point out how risk is addressed throughout DAD.
Identify risks - Are you suggesting we add Qualitative analysis as an option? Also, spikes should appear as an option for the Address Risks goal.
Explore risks - Agree about requirements incertitude and lifecycle. Adding them as options. Also agree about your thoughts on quality risks, will rework the description.
Track risks - I'm not sure I agree with you. Addressing the risks iin the risk list/backlog will often generate work that appears in the work item list/pool. For example, doing a spike or implementing several stories to prove the architecture. Some risks can be addressed quickly with a work item or two, but some are addressed over time. The point is that they're related but have different lifecycles, hence risks and work should likely be tracked separately. I will discuss this better in the description of this decision point.
Combining with Address Risks - This is my thinking too, but I wanted to get feedback before any sort of combination effort.
Thanks! Great catches.
Document a Risk - Not sure I want to go into formatting issues as that tends to be tool dependent, and situation dependent for that matter.
Identify a Risk - Agreed, happens throughout the lifecycle. I suspect we're going to be combining with the Address Risks goal.
@Jerry: Agreed. Added to the section about exploring risks. Also going to mention in the Document a Risk decision point.
So, based on your feedback I now have several hours of update work ahead of me. Thanks! I think. ;-) Expect an updated excerpt later today.
Whilst the focus of this goal is on risk. Traditionally, people still think of RAID, Risk, Assumptions, Issue and Dependencies. A paragraph recognising this would be helpful. Assumptions and issues are less of an issue when explaining to others why risk has been given a particular focus. However, any guidance on how to handle or manage dependencies would be helpful when explaining to others.
I feel identification of Risks is not just an Inception activity but also an activity which can happen throughout the life cycle. New risks can be identified even after the Inception stage. Have we considered for this?
Under Identify Risks -> Document a Risk, is there any particular format that we want to recommend/provide as an option to make the risk description and impact more structured and disciplined and easy to integrate with a product backlog (if one chooses to), as compared to free text...
© 2013-2020 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA