Risk Management in Scrum

During a recent Sprint Retrospective, my team started discussing unexpected obstacles that they encountered during the sprint. In most cases these obstacles were mitigated and didn't prevent the team from achieving the sprint goal. However, these obstacles were hindering the team in a different way: the team was losing confidence.

Constantly encountering unexpected roadblocks was making the team feel as though they didn't have control over the sprint plan. Moreover, the team was feeling rushed and stressed. To better understand my team's situation, consider the following scenario:

Daniel's boss asks if Daniel can make a coffee run and be back in time for a 12 o'clock sales meeting. Assuming he only needs to walk to the coffee shop around the corner to buy the drink, Daniel agrees. But, just after Daniel agrees to run this errand, his boss tells him that he would like coffee from the specialty shop three blocks away. A slight change of plans, but if he drives there Daniel should still have enough time.

At 11:25 a.m. Daniel hops in his car and starts driving towards the shop. Just as he gets to the main road, he encounters a line of traffic cones: the road is closed for paving. So, he takes the detour.

At 11:35 a.m. Daniel arrives at the coffee shop, parks his car, and walks in to place his order. When it's time to pay, the cashier tells Daniel that it's cash only. He frantically looks in his wallet but finds no cash. So, Daniel runs down the street to the nearest ATM, gets some cash, runs back to the store, and pays for the coffee.

At 11:45 a.m. Daniel is in his car on the way back to the office. He makes it to the office parking lot just five minutes before the meeting, rushes upstairs, almost spilling the coffee, and sprints to the conference room.

At 11:57 a.m. Daniel gets to the conference room and hands the coffee to his boss. As Daniel catches his breath, his boss takes a sip of the coffee. "I prefer it black," he says.

While Daniel was able to get the coffee and make it back to the office by 12 o'clock, he had to rush, got stressed, and ended up getting the incorrect order for his boss. Why? Daniel was lacking necessary information and didn't consider possible risks.

Assuming he only had to go to the coffee shop around the corner resulted in Daniel committing to a task that was a tight fit for the allotted timebox. Had Daniel known his boss wanted coffee from the specialty coffee shop, it's possible Daniel might not have committed to running the errand at all. Or, if Daniel had considered that he might encounter unexpected obstacles such as the road closure and needing cash for the coffee shop, he may have approached the task differently.

Like Daniel, my team needed more information up front. One of the major benefits of Scrum, in my opinion, is that the people doing the work (the development team) have control over what and how much work they commit to. Unfortunately, my team was not experiencing this benefit. They had control over what user stories were added to the sprint plan but there was a lot about those user stories that was still unknown.

To help the team acquire more information, during Sprint Planning the team tasked out their user stories. In other words, the team outlined what needed to be done for each user story to be accepted. This exercise not only helped the team have a better understanding of what they were committing to, but also helped them identify potential blockers and mitigate risk before it stumped their progress. Having this information and being proactive enabled the team to become better prepared for their upcoming sprint.

Even when working within an empirical framework such as Scrum, it's impossible to have a project with complete predictability. There will always be hidden obstacles and risks to a project; but with proper planning, teams can manage risk and regain control over their work.