Getting Started with Dynamic Range

Step 1 : Establish The Maximum Responsible Size

One of the key advantages of Dynamic Range Estimation (DRE) is that it facilitates fast visual comparison of scale and risk associated with requirement estimates. The maximum responsible size (MRS) provides a visual point of scale and a context against which these comparisons can be made. It is the MRS that dictates the boundary of the triangles that are visible on all DRE visualisations.

DRE defines the MRS as:

“The largest size of requirement that a programme of work can consistently deliver to an agreed schedule”

The concept of a MRS is present in all agile methodologies, for example, iterative methodologies such as Scrum and XP apply this principle with the practice of time-boxed iterations; the MRS in this case being the length of the iteration. This may be one week, two weeks or, in some cases, one month. Kanban also applies this principle by establishing work in progress limits to reduce cycle time, thus ensuring that the time required to complete the work in progress will not extend to a level that incurs delay beyond customer expectation.

DRE does not prescribe a maximum size; only that one is defined. In the case of a large organisation, this may be three months; for a small, agile co-located team, it could be as short as five days.

A key point to remember is that across multiple estimate diagrams it is essential that the MRS and the scale represented on the diagrams remains consistent. Without a consistent scale, visual comparison becomes impossible.

Tip: If you are using the templates that are free for download on this site you set the MRS by altering the maximum value on the vertical axis of the triangle radar chart.

Step 2 : Estimate

We now need to capture the requirements for estimation. There are two key points to remember regarding the estimation exercise:

1) Ensure that the estimates are provided by the people tasked with doing the work or, at a minimum, by skilled professionals who have insight and understanding into the nature of the work.

2) Invest the minimum amount of time necessary to arrive at the initial estimate.

The purpose of this first pass estimation exercise is not to produce an accurate, risk-free estimate but to provide an early estimate and indication of levels of risk associated with that estimate. After this first pass estimation the difference between the minimum and maximum effort may be significant. This is totally acceptable within DRE and it is important that we communicate this to our stakeholders and customers.

Move quickly through any list of requirements and ensure a fast paced discussion.

If you are estimating with a team try to avoid getting drawn into long debates over alternative solutions to the problem. It is not uncommon during estimation for debate to arise over the amount of effort required to address a requirement. These discussions are extremely valuable as they usually represent the first stage of exploring solution alternatives and design propositions. We will return to this debate later, but it is not the outcome we are looking for with the first pass estimation exercise. In these cases, find a middle ground and then demonstrate the levels of uncertainty regarding the solution with upper and lower bound percentages. Capture some of the key points regarding the debate and move on to the next requirement.

We suggest capturing estimates with a lightweight estimation template, then using this information to produce the DRE visualisation. This seems to result in a more honest estimate of risk, especially when working with teams who are new to DRE. The visualisations are a powerful communication tool; when teams are estimating and they see the visualisation in front of them, it can affect their estimation and anchor their estimates. So, for the first pass estimation, capture quickly and produce the visualisations afterwards.

Step 3 : Prioritise & Establish the Maximum Responsible Forecast

For this stage we need the DRE visualisations. Find an area that gives you space to work, and attach the visualisations to a wall or whiteboard. Place them on the wall in a manner that they are close to each other so that you can make a visual comparison between the estimates, and then step back.

We should now begin to introduce the idea of prioritisation. Attempt some form of basic triage to remove any overtly large or risky requirement solutions that fall well outside the boundaries for the level of investment that could be tolerated. When going through this process keep in mind the principle:

Just enough information to make a decision, no more and no less.

Work through the estimates with your stakeholders and teams. Compare the size and regularity of the triangles formed by the DRE visualisations. Consider how many of the estimates fit within the MRS and, if they do, what is the potential for these to extend beyond this maximum?

Foster debate between customers, stakeholders and those who provided the estimates regarding the risk associated with estimates that form irregular shapes on the DRE visualisations. Ask questions which explore why these estimates contain high degrees of uncertainty. Is this uncertainty due to lack of information regarding the original requirement, or is it due to risks associated with the technical implementation? Maybe both? Also, take time to explore why those estimates which form regular triangles represent higher degrees of certainty. What assumptions were made during estimation that gave these levels of confidence? Are the requirements well understood? Is this something we have done previously?

DRE is intended to reduce the waste of overestimation and provide a fast feedback mechanism to support decision-making in the requirements prioritisation process. Value should be the primary characteristic by which requirements are prioritised, but level of investment to deliver and the associated levels of risk are also key inputs to the prioritisation process. With DR we use these three characteristics to form a priority list of how we want to address development incrementally.

Work hard to apply the ‘just enough information’ principle and, as a requirements prioritisation begins to form, ask the question: How far ahead should we be providing a forecast with our estimation? Also consider the following question:

At what point in the future does our ability to predict circumstances become so tenuous that the definition of value attributed to those requirements becomes unreliable?

With the DRE method we answer this question explicitly and define this value as the maximum responsible forecast (MaRF). We also consider that time spent reviewing any requirements that have no likelihood of being delivered within this time threshold represents an irresponsible waste of resources. These requirements remain on our requirements inventory with no further refinement until they are prioritised to the point that they fall within this time threshold or are deleted due to no longer being required.

Step 4 : Review & Establish the Minimum Responsible Forecast

We can now begin to review and refine the estimates that will potentially fall within the time threshold established by the MaRF. This raises two further questions:

1) To what degree should we refine our estimates?

2) When will we know to stop expending our resources on estimation and begin development?

To answer these questions and to support decision-making, DR advocates one further practice, and that is to establish the minimum responsible forecast (MiRF). DR defines the MiRF as:

The minimum amount of time a programme of work should forecast development progress to facilitate consistent delivery.

The concept of cadence is present in all agile methodologies. Cadence or development rhythm ensures periodic visibility into development progress and also ensures enough short-term stability so that planning and coordination are possible. Teams and organisations coordinate schedules around cadence events, examples of which include daily stand-ups, product reviews and monthly release plans. Coordination plays a vital role in IT development, and the MiRF is intended to provide just enough short-term stability to allow for coordination across multiple teams within a programme of work or across organisational boundaries.

DRE does not prescribe a MiRF, as this will vary by organisation and development methodology employed. In an iterative development scenario with no external dependencies, an example might be the length of one iteration or possibly two. In a different scenario for a programme of work with many external dependencies, the MiRF may need to be longer to facilitate coordination across organisational boundaries and scheduling of external resources.

We can now consider our two questions regarding when to stop estimation and begin development. Within the time threshold set by the MaRF we would expect to see just enough reduction of risk and requirements breakdown to ensure confidence to proceed over the medium term.

Within the time threshold set by the MiRF we would expect to see a further reduction of risk and requirements broken down to something that falls within the MRS. To achieve this we bring the development team together with our customers and stakeholders to examine the requirements and explore solution alternatives. It is during these conversations that we begin to form concrete design decisions and break down the requirements into achievable goals.

As soon as we have this information, development should begin. As development proceeds, we incrementally refine our estimates in light of new information learned from the development process. We then continuously and incrementally reduce risk and break down requirements within the boundaries set by the MiRFs and the MaRFs, constantly keeping pace with development progress.

Example of a Dynamic Range Estimation wall…