How I think of Scaled Agile Estimation

How I think of Scaled Agile Estimation

In Scaled Agile understanding the overall capacity of your Agile Release Train (ART) is extremely important to determine what is achievable and when by a collection of Agile teams.

Scaled Agile Estimation Philosophy and Mindset

In my articles, I typically write about my experiences of implementing SAFe in the Real World giving a step-by-step ‘how-to’ guide to solve a specific real-world issue. However, before we can get into the techniques of how to determine the true capacity of your ART, which will be the subject of a future post, in this post I want to talk about the importance of understanding the mindset behind Agile and Scaled Agile Estimation.

Understanding and being able to explain the Philosophy of Agile Estimation is extremely important so that executives and stakeholders are clear on the pros of Agile Estimation as well as its limitations. The underpinning philosophy of Agile Estimation is largely the same whether we are talking about a single team or a group of teams organised using a Scaled Agile approach. Additionally, understanding how an Agile approach differs from a Waterfall approach to estimation is also valuable so that stakeholder expectations can be managed effectively.

Philosophy of Agile Estimation

Rather than diving into a detailed analysis exercise to determine sizing and / or costings, the focus when estimating in Agile is to determine a rough ‘order of magnitude’ size and scale of the requirement and then determine one’s speed or velocity. We then use this velocity and the rough sizing to determine how quickly we are likely to achieve a specific outcome continuously measuring our progress and making adjustments as we proceed.

An Example

For example, if you had to travel between London and Glasgow we would determine the overall distance between these two destinations (order of magnitude size of the problem) and once we had determined your true average speed for a small leg of that journey including any traffic, breaks or break downs! we would be able to extrapolate how long it would take to complete the entire journey. In this way we determine real-world performance in a comparable environment and then use this to extrapolate an estimate of both cost and time.

Scaled Agile Estimation Example

Estimation in a Waterfall Project or Program

The Waterfall approach would focus far less on previous performance (yesterday’s weather) and more on a detailed survey approach detailing exactly what is likely to occur and any obstacles that may be encountered.

Waterfall Estimation Example

The following are some of the important elements of the philosophy underpinning the Agile approach to estimation:

Effort vs Accuracy Curve

When estimating costing and timelines I frequently seeing a lot of effort being spent in estimating and determining the size and timelines of deliverables. Mike Cohn in his excellent book Agile Planning and Estimation (1) shows how extra effort beyond an initial ‘light-touch’ point doesn’t necessarily improve predictability. See graph from his book:

Agile Estimation Accuracy vs Effort

In our example, it would be easy to expend a huge amount of effort doing a detailed upfront analysis and a detailed survey of our road trip to Glasgow, in extreme circumstances we could even send a scouting party ahead to see actual conditions on the road and anticipate the challenges thoroughly. A huge upfront effort such as this can actually be counter-productive often resulting in a reduction in the delivery of value. Please be careful not to fall into this trap when determining the velocity of your Agile Release Train.

Agile Estimation should be quick, relative and built into the process.

Previous Performance

In Scaled Agile Estimation we focus on using our previous performance as a barometer of future performance. If you have an Agile Release Train how did you do in previous Program Increments ? If you have a team how did they perform in previous sprints ? The important thing is knowing how teams are performing in your unique environment – warts and all.

In our road trip example, if we had historic information on how fast these vehicles had operated in a similar journey in the past including comfort breaks, traffic jams, accidents and other challenges, then we would use this as a barometer for the kind of performance we could anticipate in the future. How long had a similar journey taken in the past? Were there comparable conditions?

Relativity

Whilst we want to use our previous performance as an indicator of future performance, we may not have an identical experience with which to compare it with.

This is where we would use relative estimation, estimating two comparable but distinct outcomes against one another.

In our road trip example travelling from London to Glasgow, we could use a previous journey, but what happens if you haven’t made this journey before. Maybe you have made other journeys in difference circumstances. Maybe it was to another location – London to Manchester – a percentage of the journey. Could we use this information ?

Or, maybe it was from London to Glasgow but it was under different conditions at Christmas or under snowy conditions, or you had a major mechanical failure. We can use this information as a baseline from which we could estimate future journeys relative to this one.

Regular Check Points

When using an Agile approach, we have regular checkpoints to see how we are doing so that we can adjust our approach as often as is necessary. In our example, we would evaluate at specific and regular points in our journey to determine how we were doing at each leg in the overall journey. We could then use this information to determine how and when we were likely to arrive at our destination, adding more detail and confidence to our arrival date/times and overall costs as the journey progresses. This also gives us an opportunity to adjust our approach based on the conditions we find at that moment in time giving us a large degree of flexibility to overcome unexpected challenges.

Limits of Agile Estimation

Whilst the Agile approach to estimation is a vast improvement upon waterfall methods, there are still limitations of this approach which need to be borne in mind:

Lack of Precision. Neither approach will give you precision. Given a complex environment with an almost infinite number of variables, it is incredibly difficult if not impossible with current approaches and philosophies to come up with a precise estimate of either cost or time for a specific scope. Rather what we aim for is an accurate range together with regular and pro-active monitoring to determine early on if the estimate is unlikely to be satisfied.

Historic Performance. Agile estimation depends upon having some indication of previous performance from which we can extrapolate future performance. The premise for Agile Estimation is simple:If we could do it before in this environment, within a certain time-frame and cost, we can probably do it again. Where an activity or endeavour is brand new or a team is new and this information is unavailable, we can do a small amount of activity to determine how fast we can go and extrapolate from there.

Philosophy of Agile Estimation

Whilst Agile estimation does have its limitations with regards to precision in a complex environment, it does provide a dependable range of anticipated outcomes in advance. The more information that is available on previous performance the better the predictability of achieving a certain outcome within a certain time-frame and/or budget.

The challenge is moving from a commitment oriented mindset locking down scope, time, cost, quality and forcing seldom fulfilled ‘promises’, to a predictability oriented mindset where the focus is understanding and measuring current performance and capability accurately so that we can use this as a predictor of future achievement.

Predictability is more important than commitment

Executives need greater predictability rather than broken promises. Adopting Agile in a disciplined way enables us to create that predictability. When we are using an Agile approach yet lack predictability, it is a sure sign that something has gone wrong and needs fixing. Creating a culture where we understand our true capability at the Agile team level and the Agile Release Train level is essential to be able to provide the confidence the business needs to execute in an ever changing and demanding world. Exactly how we do that for an Agile Release Train will be the topic of my next blog post.

What challenges have you found when using an Agile approach to estimation ? Please leave your comments below.