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
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
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:
Great Scrum teams manage risks and issues by:
Discussing/identifying risks before the start of a sprint and at each sprint kickoff (sprint planning session)
Identifying sprint team member availability and capacity during sprint planning
Planning six hours per day per Scrum team member of work, keeping about two hours per day in reserve (the "slush fund")
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
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?
Adjusting/de-scoping the sprint as needed, if risks and issues impact the sprint more than the risk reserve allows
Following the steps outlined above
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)
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