Assumptions, Risks, and Dependencies in User Stories
DZone (Agile Zone) | Mar 06, 2019
Don’t gamble with your project. Learn where these three often hidden elements may be in your user stories and how they can derail your project.
Assumptions
An assumption in requirements is an assertion on which a given requirement or set of requirements depends.
There are 3 fundamental problems with assumptions:
An assumption is not quantified in terms of likelihood. It is nakedly stated as a fact.
An assumption is not quantified in terms of impact. “What happens if this isn’t true?” is not part of the structure of an assumption.
An assumption has no required or inherent follow-up. In my experience, assumptions are frequently placed in requirements documents and then forgotten about. It is “assumed” that someone has added a tickler in a project plan to check on the status of an assumption, but that frequently doesn’t happen.
Assumptions were a way of attempting to formalize connections to external conditions (systems, tasks, states, etc.) that would later be called dependencies.
Dependencies
A dependency is simply a connection between two items (often tasks or teams, but can also apply to components, modules, or other software structures). A dependency asserts that the dependent (client) state cannot change (start or finish) until the dependency (precedent) reaches a certain state. There are four types:
Start/Start – item A can’t start until item B starts. Cars in a motorcade can’t begin moving until the lead car begins to move. In fact, each car in a motorcade can’t move until the car immediately in front of it moves.
Start/Finish – item A can’t start until item B finishes. The second stage of a rocket can’t fire until the previous stage has finished.
Finish/Start – item A can’t finish until item B starts. Less common in software development, but an example would be an evening security guard who can’t end his/her shift until the guard on the next shift clocks in and begins their shift.
Finish/Finish – item A can’t finish until item B finishes. My accountant can’t finish our income tax preparation until we have finished assembling all requisite data from the year.
Dependencies have similar problems to assumptions, though to a lesser degree.
Risks
Generically, a risk is something Bad that might happen (in this context we add “…that affects the timely and correct implementation of software”). More formally (at least in Project Management circles), a risk is a potential negative condition that can be quantified in two dimensions:
How likely is this condition to occur?
What is the impact should this condition occur?
It is important to note at this point that risks should be identified which affect the project, not the company.
It’s also useful to note how well this approach (originating in Project Management) dovetails with Agile. Identifying and quantifying risk gives Agile teams the ability to prioritize tasks. Some people are insistent that risk is a potentially negative external condition that can affect a project. But internal risks need to be identified and quantified as well.
Which brings up the second beneficial aspect of using the Project Management approach to risk: it requires the creation of a plan to mitigate any negative impact on the project. This has an implication that isn’t immediately obvious: risks that can’t be mitigated are effectively not risks.
Since dependencies are a form of risk, it stands to reason that they should be included in any mitigation plan.
Recommendations
Train your teams to avoid the use of assumptions in user stories, use cases or any requirements document. Excise existing assumptions from such documents by examining each one in detail, then either a) removing the assumption unilaterally, or b) converting the assumption into a risk or dependency.
Use dependencies specifically to document the order of events, steps or stages (not components), and be clear about how the term is being used. Treat all dependencies as risks.
Use risk to quantify likelihood and impact, using whatever scale is appropriate for your organization. Use the term and scale consistently across teams and projects.
Establish a mitigation plan for (at least) high-priority risks.
Remove any identified risks that have no possibility of mitigation, most effectively by bumping it up to any architectural planning group that oversees long-term development practices.
Author = Tom Fulton (Agile Zone)
URL = https://dzone.com/articles/assumptions-risks-and-dependencies-in-user-stories