Risks and Issues: How They Apply and Are Worked in Scrum Sprints

What Risks and Issues Mean for Your Agile Teams

28 February 2014


Scrum teams try, where possible, to identify and plan for risks before the start of a sprint. This helps them better plan and pack the sprint with the correct workload based on their available resources and capacity. Unfortunately, issues are the more frequent event a Scrum team has to deal with as, many times and especially for Scrum teams that are just getting started, the event was not foreseen. Instead, an event occurs in real time during a sprint, which by definition makes it an issue.

Let's do a quick level set on risks and issues, shall we?

RISK = Future tense

While entire volumes have been dedicated to risk, at a high level, PMBOK defines a risk as an uncertain event or condition that, if it occurs, has a positive or a negative effect on a project or sprint. It is important to note the uncertainty or probability of a risk. The event has not happened, but there is a chance it could occur.

Issue = Current or past tense

An issue is an event or condition that has already happened and has impacted or is currently impacting the project or sprint. There is no uncertainty or probability aspect associated with an issue. A risk that occurs becomes an issue, or a "realized risk." Not all issues start out as risks. (Would be great if we had a crystal ball and could see into the future and identify and plan for all unknown risks. . . . But I digress.)

Risk versus issue probability

For the mathematicians among us, the probability of a risk may range between 0 and 100 percent, but it cannot be 0 or 100. The probability of an issue is always 100 percent. The impact of the risk or issue: Let's save that for a future article.

Risk versus issue -- Scrum management

Good ScrumMasters create a risk reserve, usually by holding back or stashing some team member hours in a sprint. Your risk reserve is used and drawn down during the execution of a sprint as a risk is realized, or when an issue arises. This way, while you may not know everything that might impact the sprint, you have something set aside to help the Scrum team absorb the impact. Old ScrumMasters like me call this our "slush fund."

Good Scrum teams manage risks and issues by:
  1. Discussing/identifying risks before the start of a sprint and at each sprint kickoff (sprint planning session)

  2. Identifying sprint team member availability and capacity during sprint planning
  3. Planning six hours per day per Scrum team member of work, keeping about two hours per day in reserve (the "slush fund")
  4. Planning out the target flow of the user stories at sprint planning (Dev to DIT to SIT), which helps identify flow and risks for user stories and the overall sprint
  5. Conducting daily stand-ups and answering the three magic questions:
    • What did I do yesterday?
    • What do I plan to do today?
    • What are my blockers/issues that I want to share with my team?
  6. Adjusting/de-scoping the sprint as needed, if risks and issues impact the sprint more than the risk reserve allows

Great Scrum teams manage risks and issues by:
  1. Following the steps outlined above
  2. Striving for honesty and transparency in tracking, recording, and talking about their risks, issues, and challenges as a Scrum team (The old adage, "We cannot fix what we do not acknowledge and measure" is very, very true for Scrum teams)
  3. Growing and maturing as an accountable, self-managing team; becoming a team that is more able to identify, plan for, and handle risks (and issues) for that particular product



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.8 (4 ratings)

Comments

David Lowe, CSP,CSM, 2/28/2014 8:02:51 AM
I'm not sure about some of this post. For example, "Good ScrumMasters create a risk reserve, usually by holding back or stashing some team member hours in a sprint." Are you capacity planning by breaking work down into hours? The practices you describe sound more like project management than Scrum to me.
Hunter McCluer, CSP,CSM, 2/28/2014 11:07:50 AM
David, Great question. In the DOD our teams estimate stories by hours, not by points. While teams know the hours are estimates, they try not to book / pack their sprints above 80%. When things come up, unforeseen complexity, or outside impacts, team members have a few hours / capacity in the Sprint to absorb the impact and still delivery the Sprint package / work as estimated. You are correct, our teams use a blended approach of Scrum and Project Management to seek to achieve the highest return from each Sprint.
Pryor Rowland, CSM, 3/3/2014 4:43:15 PM
I also have used the practice of reserving 20% of capacity as contingency, to use a PM term. This was not concealed as a "slush fund" however - I find the term somewhat unpleasant. Instead the 20% contingency is openly discussed with the PO at sprint planning as to which lesser priority items would be included in the event that the spare capacity is not required to address realised risks. This practice originated with DSDM I believe.
David Lowe, CSP,CSM, 3/6/2014 3:55:33 AM
Your Definition of Done says that you estimate stories by hours?

I'm confused why it includes that kind of information. As Dhaval Panchal said in a previous post (http://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-%28dod%29) a "Definition of Done is a simple list of activities that add verifiable/demonstrable value to the product" and focuses on "value-added steps"; I don't think planning fits any of these.

Why do you capacity plan rather than use story points/velocity? I've seen only one team where capacity planning was (maybe) preferable to story points: the team comprising individuals with VERY specialist knowledge dealing with VERY silo'd requests that were small.

You might want to take a look at the #NoEstimates discussion that the likes of Woody Zuill and Neil Killock have been having: it encourages you to question your processes and asks some very thought-provoking questions that I think you might benefit from. I've written a summary of the debate here: http://scrumandkanban.co.uk/no-estimates/

Hope that helps.
Hunter McCluer, CSP,CSM, 3/7/2014 8:33:05 AM
Hi David,

Great post and thank you. For my teams, as they cannot fully shield themselves from changes in a Sprint, the 20% reserve allows them to adopt / deal with most changes, and keep their Sprint commitments.

I will bring the NoEstimates discussion up with a few or our teams, and see fi they want to adopt / use this process.

Happy Day,

Hunter
Adam Zuzanski, CSP,CSM,CSPO, 3/13/2014 10:17:56 AM
Hi Hunter,

I just had a chance to read through your article and decided to add my 2p.

I agree with most of what you wrote about managing risk, but I believe that there is even more mechanisms in Scrum that make project less risky.

For example:
- Retrospective (and team empowerment in general) allows to mitigate risk of morale problems.
- Using non-linear estimation scales and bucketing concept for virtual units like SP allows to mitigate impact of less than perfect estimation.

In my opinion you can handle common project risks just by following basic Scrum techniques.

It's good to adopt contingency when using hours. In case of using Story Points it's redundant.

Regards,
Adam.

You must Login or Signup to comment.