As a Tech Lead or Project Manager using Agile, one of your most crucial practices is cultivating an organized and detailed backlog of stories. That should include what I call derisking: breaking down multifaceted problems into actionable work, outlining the technical hurdles of each story, and providing guidance on how to tackle them.
Of course, this practice can be taken too far, eating up all of your time and depriving your team of the opportunity to learn. For the sake of discussion, I’ll call this practice unrisking.
Unrisking Is Unsustainable
So what does unrisking look like? You insist on fleshing out each story before handing it off to another developer. You personally vet each problem and leave a detailed story for other developers. Sounds great, right? Actually, this type of project management tends to run into a number of troubles.
In the beginning, everything will probably go smoothly. However, you’ll now have to shoulder additional stress while planning and looking forward. As this continues, you’ll become a silo for all architecture and system design decisions. This will leave developers with only a glimpse of the overall design philosophy.
Eventually, you’ll burn out and become overwhelmed by the immensity of providing “stability” for the team. At the end of the day, you’ll spend so much time unrisking that you’ll fail to fulfill other aspects of your job. And this loss of planning, teaching, and reviewing the current state of the project will become cyclical.
Additionally, your team will lose out on the chance to problem-solve and to learn. When they see only _what_ is done but not _why_, it limits their growth. Challenging a developer with a hard feature or new technology gives them an opportunity to flourish.
Benefits of Effective Derisking
So if I’m so vehemently against unrisking, what makes derisking any better? I will start by explaining what it looks like for me in practice.
I start by analyzing the scope of a project and the technologies involved. My experience helps me identify the technical hurdles, even without a specific solution. From here, I create stories and define features as normal. I prioritize stories based on both the clients’ goals and the system’s architecture.
Now comes the hard part. As I groom stories for a sprint, it’s my responsibility to outline, at a high level, how the problem can be approached. I focus on critical work needed to meet requirements and understand areas of risk. Story derisking should not be a prescriptive plan delegating exactly how components fit together, but rather a descriptive outline sketching a high-level view. This is not to say I don’t provide my input, but it comes as advice and resources to help reach the best solution. Noting complex interactions and highlighting existing solutions provides a starting point for developers.
When derisking is done correctly, the heavy lifting of development is shouldered by the developers. I am able to step back and provide guidance. This flexibility allows me to meet the demands of an evolving project without having to solve every complexity. This provides balance and fulfillment for everyone involved.
Honing Your Derisking Skill
The temptation to unrisk a story will always be there, so try to keep the distinction in mind:
| Derisking | Unrisking |
| Outline general approach | Spike out a possible implementation |
| Point to resource of similar solution or helpful documentation | Be prescriptive of the solution instead of description of the goal |
| Highlight critical work or areas of possible pain | Take on the lionshare of problem solving for your team |
When you practice derisking, you’ll accelerate backlog grooming and provide opportunities for developers to learn with your guidance. Hopefully, this insight will prevent your burnout and set up a framework for project success.