By Kristi Salmi, Moneycatcha

In the initial stages of a project, estimates of time and resources are typically off by a factor of four in each direction. The exact requirements and resources available aren’t clear, and can be four times too high or too low. This is the “Cone of Uncertainty”, a term coined by Stephen McConnell in his book Software Estimation: Demystifying the Black Art.

It’s challenging to operate within uncertainty. Say you have an agile DevOps team working on a project to build a solution for the organisation. There’s a need to plan and coordinate resourcing for testing, change management, training and implementation. But the DevOps team won’t make any estimates or commitments because they’re in the cone of uncertainty.

This uncertainty makes estimates difficult. But there are some tools and techniques to help remove some of the variability.

1. Set goals and priority sliders

At the start of a project, stakeholders need to agree on the goals they want to achieve. Priority sliders then rank outcomes from highest to lowest priority, such as quality, security, timeframe etc. These goals and priorities, which determine the MVP (minimum viable product), need to serve as a continual reference point and reminder.

2. Domain Driven Design

Using domain driven design techniques, such as Event Storming, is a great way to map out visually what is required. Event Storming involves the Product Owner and business stakeholders mapping out the actors involved and all the events. The DevOps team will then walk through this with the business representatives providing an opportunity to ask questions and gain a shared understanding, of the process, requirements and terminology.

The output created from the Event Storming session is then used to create Product Backlog Items (PBIs) in the form of User Stories that the DevOps team will work on to build the product / solution. The Event Storming process can be repeated throughout the project to map out happy paths and unhappy paths for all requirements, whether they are features, functionality or processes. 

3. Define an MVP

Confirming and communicating the MVP to the DevOps team eliminates uncertainty and variability. Once the MVP is released, subsequent iterations will see additional features and functionality added, until the value added is no longer worth the cost of continued development.

4. Ready and Acceptance Criteria

Before a PBI is accepted in the Sprint Backlog to be worked on by the DevOps team, the requirements need to be clear. This is the Definition of Ready (DoR) criteria. If a PBI doesn’t meet the DoR then it shouldn’t be worked on. A PBI should also have acceptance criteria included before the team agree to work on it. If the team agrees that they understand a PBI and accept it into the Sprint Backlog this means there’s no uncertainty associated with it.

5. Backlog Refinement and Story Elaboration

There are a number of meetings held that also assist in reducing uncertainty.

• Formal Backlog Refinement meeting with relevant SMEs, stakeholders and technical leads to review the PBIs and prioritisation
• Story Elaboration meeting where the PBIs are played to the DevOps team, who can ask questions and raise concerns, before accepting items into the Sprint

6. Inspect and Adapt

Teams should have an inspect and adapt meeting everyday (Daily Stand-Up) as well as at the end of the sprint (Sprint Retrospective). The purpose of the Daily Stand-Up is to identify any challenges, including anything that’s unclear, so the team can address them immediately. Likewise, the Sprint Retrospective is an opportunity for the team to review their performance and to identify things they can improve or would change.

7.  Story Point Estimation

Using relative sizing in estimating the amount of work required for a PBI is a really useful technique, especially for providing estimates to the business or a PMO. Humans are better at estimating the size of something in comparison to something else.

Really, it’s only during the early part of a project that a team is operating in the cone of uncertainty. If more than 20% of the project time has elapsed and the team are unwilling to provide estimates because there’s still uncertainty, try some or all of the above techniques.

If you are over a third of the way through a project and still having these problems the team may be operating in a cloud rather than a cone of uncertainty. If this is the case it’s highly unlikely your project will be completed on time, if at all. It may be time to re-evaluate the project as well as the team composition and skill-sets.