Uncertainty is everywhere. I’m writing this while waiting for a plumber who is already nearly an hour late. Is he still coming? When?
My weather app says it’s supposed to be clear today, but it looks like rain to me.
And earlier today I asked my developers for some changes. I know generally what I want, but I don’t have every detail figured out. So with things uncertain in my mind, I’ve introduced uncertainty into their lives.
With so much uncertainty everywhere around us, it seems like we’d be comfortable with it. And you’d think that teams working with agile methods like Scrum would be used to not knowing.But most are not.
I’m not. It really doesn’t matter when the plumber shows up. There’s plenty of time before I need to be anywhere. So the uncertainty around when he’ll arrive shouldn’t bother me. But it does.
Agile Teams Need to Live with Uncertainty
It’s critical that Scrum teams learn to live with uncertainty. In an agile project, or any project for that matter, not everything will, or can, be known upfront. The details about a product emerge over time.
That means that neither a team nor its stakeholders knows all the requirements upfront. It’s simply impossible. Some requirements will emerge throughout the development process as users are shown preliminary versions of the product.
Similarly, the details of a user interface cannot be defined up front. A database cannot be perfectly designed up front.
What Happens When We Try to Eliminate Uncertainty
When team members are uncomfortable with uncertainty, they exhibit certain telltale signs.
First, team members often expend significant effort in story writing workshops, refinement, or sprint planning meetings in an attempt to capture all details prior to starting work. At some point, there becomes a rapidly decreasing value to further reductions in uncertainty. When in that position, team members would be far better off simply beginning the work even with open issues remaining. The best way to remove the remaining uncertainty is often to just get started.
Also, teams that want to eliminate uncertainty often become very resistant to change. Team members want to lock down requirements rather than embrace the inevitable changes that result from showing a product to users.
Finally, when a team is uncomfortable with uncertainty, its sprint planning and product backlog refinement meetings will often take excessively long. Those agile planning meetings should be used to confirm that enough is known to proceed, not that everything is known. Teams fearful of uncertainty will attempt to drive out all uncertainty during these meetings.
3 Ways Scrum Masters Can Help
Fortunately, there are a few things Scrum Masters can do to help a team become more comfortable with uncertainty.
1. Understand Estimates Aren’t Guarantees
Scrum Masters can start by ensuring there’s an appropriate organization-wide understanding that estimates are estimates and not guarantees. Associated with every estimate is an often-unstated probability of that estimate being correct.
If a team says they can write a credible competitor to Microsoft Word in a week, there is a roughly 0% chance of their meeting that estimate. If instead they estimate they can do so in a 100 person-years, that estimate comes with a much higher probability.
It is important that stakeholders, project managers, and other recipients of a team’s estimates understand this.
A team can use an estimate as the basis of a commitment (or, within reason, a guarantee). But a commitment implies a much higher probability of being met. And for that, the team will need to state a longer amount of time.
A team might, for example, estimate that the most likely duration to complete something will be two months. But if pressed to commit, they’d say three months—to be safe—when based on a two-month estimate.
Once this is broadly understood by a team’s stakeholders, team members can let go of some of their desire to answer all open issues before starting work on an item. But if team members fear they’ll be blamed when things take longer than expected, they will push to know as much as possible up front.
2. Validate the Need for Answers, But Defer Resolving Some Issues
A second way to help is to point out examples, when they occur, of a team pushing for unnecessary information. My favorite way of doing that is to tell a team, “Yes, I can see that you need an answer to that question. But do you need the answer before you start work on this product backlog item or do you merely need the answer before you finish?”
This response validates a team member’s request for more information, but helps show that work can begin without some answers.
As a practical example, consider a team building the log-in capability for a new system. Work could begin on that without knowing things such as
- How many failed attempts before a user is locked out of their account
- Exactly what criteria constitute a strong password
- What mechanism will be used for resetting a forgotten password
Answers to questions such as those are absolutely needed before the log-in capability can be considered complete. But a reasonable team member will acknowledge that work can begin in advance of having those answers.
3. Share the Purpose of Meetings
A third way Scrum Masters can help is by stressing the purpose of any Scrum meetings in which you see team members pushing unduly to remove uncertainty. The goal in iteration planning, for example, is to select the approximate or right amount of work into the iteration. Doing that does not require an answer to every open issue.
Uncertainty can be uncomfortable. And many of us are unlikely to ever become completely comfortable with it. But getting a team to accept uncertainty rather than attempt to eliminate it is necessary to succeed with agile.
What Do You Think?
Are your team members comfortable with uncertainty? What did you do to get them past any discomfort with uncertainty? Please share your thoughts in the comments section below.