Uncertainty management is difficult to pin down but two fundamental questions in particular have been central to recent discussions.
The first fundamental is regarding visualisation of uncertainty: Can we visualise uncertainty and represent uncertainty management in a plan? If yes, and the plan is to reduce uncertainty, then can we conveniently visualise progress of uncertainty reduction against plan, and include this in a report, or on a dashboard?
The second fundamental is regarding change and extending the ideas of uncertainty management to deal with decisions affecting scope: How do decisions about scope affect uncertainty? How can we ensure that the plan is adjusted to deal with change? How does scope change affect uncertainty and risk?
The First Fundamental: Visualisation and Planning
Tackling the visualisation question first is quite easy. We remembered Mike Cohn posted (some time ago) on Risk Burn-down and we apply a similar treatment to Uncertainty Burn-down.
The planning assumption is that a project starts with a backlog of stories, and from a position where an inherent range of uncertainty has been assessed. Actions to manage and ideally reduce the uncertainty (range) can then be planned and carried out by the project. Most likely by Business Analysts and Business Champions. DevOps, Service Delivery, Change Management teams and some 3rd parties might also get involved. The general aim is to refine understanding of the requirements and improve the estimates. Perhaps incrementally, through a number of actions, involving multiple steps to improve the estimates on each story. Actions like this should be planned to complete a few days or a sprint before a story is scheduled to be included in a sprint for delivery.
The actions should make the uncertainty (range) for story estimates narrower (smaller) by a planned amount, but will not necessarily change the estimates or make them smaller. In fact, while the range in an estimate gets smaller, the estimate itself could increase. This happens often but is the subject for a different blog post.
The necessary condition is to ensure that stories are a deliverable size and their estimate uncertainty is in line with the margins that can be accommodated by contingency per sprint in the sprint plan.
Given the planned reductions, the plot of planned and actual uncertainty reduction (range) on a chart, like Mike Cohn’s Risk Burn-down Chart, might look like this:
Uncertainty (Planned vs Actual)
The Second Fundamental: Change
The second fundamental, addressing scope change and uncertainty may be less familiar and about a different question: What impact is the scope change making?
Change could be adding more work (additional scope) to a project or programme: for example a new mini-project or epic to deliver. It could also be about removing scope or, more likely in Agile, deciding that some scope is [colloquially] not worth the trouble. It is rarely the case that planned development will fail to deliver any benefit but decisions about maximising benefit, particularly where a development is not nominally part of the Minimum Viable Product (MVP), may lead teams to do something different. Doing something different might mean halting the development of some stories to allow focus to turn elsewhere in pursuit of better returns. This should never be about scope reduction but it does involve decisions to stop development on stories that inherently carry some uncertainty. So uncertainty tracking has to account for this.
Change of Plan
Adding new scope, a new epic or mini-project to the backlog, is not too difficult to represent. But, while an epic captures the big picture it can conceal unknowns or uncertainties that make it difficult to estimate confidently. Mini-projects are similar in some ways. The result of adding epics and mini-projects before they are assessed is to increase the uncertainty while the project is in flight. This can be difficult for a traditional project but for an Agile project can be shown as an injection of more work and uncertainty somewhere into the plan, and as something that has an impact on tracking.
The result might look something like this:
Uncertainty Reduction Plan (Inc. Additional Scope)
The chart shows the increase in scope and up-turn in uncertainty, but it also shows a step up in actions required to catch up and get uncertainty reduction back on track. This is what the programme and project Boards want to see in progress reports.
Change triggered by a milestone is different again.
Say the project has achieved its MVP milestone, so it is able to deliver the minimum viable product. Theoretically delivering more beyond the MVP is beneficial but, by design, the MVP milestone is often a milestone that denotes a point of diminishing returns. Beyond the MVP stories remaining will be of lower benefit than anything delivered earlier; and may generate a lower rate of return on investment (ROI). In this case, if the additional stories are not dispensable they are at least not critical and a decision to stop their development may gain some support. In particular because it may write-off actions otherwise necessary to reduce the residual uncertainty.
The rationale though, is not always clear. Deciding not to do the work on additional stories removes uncertainty and could be considered a benefit but there is more uncertainty or risk to think about. Not delivering stories that were part of the original scope (albeit not part of the MVP) might affect confidence in the long term ability of the Business to achieve its originally planned rate, or full rate, of ROI.
Talking this through led to the blog post and this is the point about change: If development continues per plan there is a cost and risk associated with uncertainty and having to do more work, which may undermine the overall benefits of the project. If development of additional stories is halted then there may be net benefit in not having to do some work, but a cost of a change in uncertainty and risk associated with the longer term potential loss of ROI.
So the business has to make a decision: is the saving on the project delivery enough to offset the potential loss in ROI?
It feels like the cancellation of some uncertainty is positive, but introducing a risk. The usual risk resolution strategies therefore apply and this is now about risk management.
Risk Acceptance: Accept the risk that ROI will be achieved at a marginally lower rate than it could have been but that the benefit of cost saving is adequate reward.
Risk Avoidance: If the project is uncertain exactly how it is going to fulfil a Business requirement, or perhaps uncertain that it can deliver a requirement or improvement in user experience that the Business is expecting, then don't do it: appeal to the Business and don't offer what is too uncertain or risky to deliver.
Risk Transfer: Transfer the risk to the Business. The Business could decide savings from uncertainty reduction and delivery by the project will support future work to protect or boost ROI in Business operations and service delivery. The Business signs off on a concession and takes on the risk.
An Agile project is willing to carry uncertainty and accept that change is good when it allows the project to be alert to changing priorities and deliver what the Business actually needs. This post explains that to be Agile projects have to plan to be responsive. It is not enough to be flexible. There is a world of difference between being flexible and having a plan. The right plan is to engage and resolve uncertainty with the Business in a disciplined Agile way.
A recent blog post 'Agile - A Bumpy Ride?' shared more thoughts about managing to plan and making decisions on cross-prioritisation that have just as much relevance here. Some of this thinking is packaged into Adapt 2.0TM (see http://www.indigoblue.co.uk/adapt), a framework we use to guide us in assisting our clients to manage the delivery of their Agile programmes. If you are interested in finding out more, then please get in touch on 020 7692 4832.