Knowing when to stop – trim that tail ruthlessly

07 July

My friend and collaborator on building our Agile Business Analyst courses (both classroom-based and e-learning versions) Steve Adolph posted an excellent discussion on the Development Knowledge blog about the importance of leaving decisions in product development projects to the last responsible moment and the shape of a healthy backlog. 

Following on from Steve’s wise words I want to talk about knowing when to stop.

Once an item has been added to a backlog there is tendency for it to take on a life of its own (no matter how small or large it is), someone who matters wants it to be included in the delivered product and they are prepared to argue for it whenever it gets looked at in a grooming or forward planning session.  The “someone who matters” could be a value manager, product owner, a technical member of the team, a subject matter expert, or any other interested party.

We know that one of the benefits of using an Agile approach is the ability to move items in and out of the backlog easily which is a great capability, enabling us to ensure that the product we build meets the customers’ needs effectively through always focusing in the next most important piece of business value.

The normal, and generally correct, approach is for the value manager to work with the team to produce a prioritised backlog with clarity on the high priority items and accepted uncertainty in the items which are further away, as shown in this diagram from Steve’s article.


Diagram of a prioritised backlog


At some point it is likely that an estimation activity will be undertaken, resulting in a budget or funding allocation to provide the team with the resources they need to build the product, with some expectation of what is likely to be delivered.

The stories which come out of the bottom of the grinder are small enough for the team to deliver using their Agile development practices, ideally they should be fully implementable (as per the agreed definition of Done in half an iteration or less – the smaller our stories when they are being implemented the better our ability to predict and plan work.

The most common approach to tracking the rate of delivery is using velocity as a metric for the work done, often reported in a Velocity Graph, such as the one below.

Image of a velocity graph

The target story points are effectively the budget that the product owner has to work with – they can add or remove stories to achieve the most valuable scope.  Another great benefit of velocity tracking is the ability to see actual progress and manage scope, time and/or money to ensure the features requested are built, for an acceptable price – as can be seen in the figure below: 

Image of a velocity graph with added story points

This transparency of the real velocity the team is able to deliver at is a huge benefit – late surprises are avoided and good decisions can be made about realistic scope management.

This is all great and making decisions in response to velocity trends is one of the key aspects of trying to maximise value returned for the effort expended.

Unfortunately, it’s not enough!  Story points are a measure of cost and complexity in the product – they don’t show VALUE.  Value and cost are quite unrelated at the epic and story level.

The reality is that the delivery of value has a significantly different shape to the velocity graph. Value will most often follow an S-curve shape, as shown here:

Image of a value vs points delivered graph

The first few iterations the team will pull  work from the backlog based on confirming or disproving some assumptions, addressing some of the important areas of uncertainty and risk and occasionally doing small experiments and spike solutions to reduce uncertainty risk through the rapid feedback cycle that Agile projects allow – the early delivery will enable the value manager to validate the concepts and confirm or deny the early assumptions made about the customer needs.  There will be a lot of learning about the capability of the team, the uncertainty in the project, the way people work together and many other aspects which need to be exposed early in a product lifecycle.  There will definitely be velocity, but the delivered velocity will not be directly proportional to the value derived from the stories.

The likelihood is that these first few iterations will not produce enough of the product for it to be truly valuable in the marketplace until enough of the stories have been delivered to cross the MVP threshold – the Minimum VIABLE Product which can be utilised beyond a select and limited group of early-adopter or test customers, something that actually does start generating at least a subset of the planned benefits.

Once the MVP has been delivered there is often a sharp upturn in value delivered – as new stories are added to the product they make it more attractive to the customers.  For a while this sharp increase in value continues as the most useful stories are delivered. The iterative feedback nature allows the team to learn what the customers REALLY want, and that is likely to be quite different to what was originally planned.  As new stories are identified they need to be added to the backlog in value-based prioritized order.

At some point the rate of value delivery tapers off – the team has built the features and capabilities which are of the most interest to the customers, and adding new capabilities does not significantly increase the usefulness of the product to the customers.  This is the point where the value manager needs to be ruthless about cutting the remaining work – yes there are plenty of epics and stories left in the backlog, yes there is more budget money in the pot, yes some people want those stories too, but is adding additional capabilities to this product actually the best thing to do with the remaining funding?

Evidence from studies of products seems to indicate that stopping work early is a very good thing.  Depending on which study you look at, somewhere between 50% and 70% of the features in a typical software product are never used.  Now, a portion of those features are built in the hope that they will never be needed – these are often the disaster recovery and security protection features which hopefully won’t be exercised. However these do NOT account for half of the work in a typical product.  Surely it will be better to stop work rather than build features which no one will ever use in the wild.

So – how does the value manager know when to stop, when enough has been delivered that we satisfy customers’ needs without gold plating the product?  This is a hard question, but one that tracking value as well as velocity can help with.  At some point the cost of adding more capability (building the next story) will exceed the incremental value derived from having the additional feature, the value curve will have flattened out. At that point the value manager should get a really sharp knife and “trim the tail” – stop building new features and allow the team to move onto another initiative which will have more benefit to the organisation.

This means that the value manager needs to keep a very careful watch on what’s happening with the stories in the grooming and planning sessions and actively questioning the explicit value of items in the backlog so that sensible business value based decisions can be made.


Image of a value vs points delivered graph showing where to trim


But how do we measure the value in a single story?  Unfortunately, the answer to that is “with difficulty”.

We can prioritise stories (we are in fact constantly re-prioritising) and we should make the effort of recording value as part of the information about a story – we record story points, perhaps we should add value points as well.   Philippe Kruchten talks about recording “utils” (utility points) rather than dollars as a unit of value, and he provides some good advice on using utils to show the value of reducing technical debt and including architectural components in the product – two aspects of value that are often hard to explain to non-technical stakeholders.

Another approach is to have stakeholders play the “buy a feature” game regularly; whenever the backlog is being examined and amended allocate a block of pseudo-dollars and has stakeholders spend as much or as little of their allocation on remaining backlog including the new or changed capabilities. Items which people aren’t prepared to spend ‘money’ on getting discarded.  The quantity of money should be diminishing proportional to the velocity delivered vs initial project planned velocity. The choices get harder as more of the product is built – early on we should get clarity on the most important stories as they will be “obvious” to the whole team.

In conclusion, in order to truly be able to maximise value and often reduce time to market, we need a ruthless, laser-like focus on value- what are the things being done which increase value (either through learning and risk mitigation) or through actually delivering  elements of the product that people will use and get benefits from.  This takes more than product ownership or business analysis mindset – it really needs a Value Management to focus in the team.

Post by Shane Hastie

Thank you!

Your details have been submitted and we will be in touch.