Operating as Head of Engineering at a Software firm, a large responsibility of the team is that of Product Delivery.

Our team needs to be working on ‘the most important’ things and be predictable in ways in which we can expect things to be completed.

Over the years I have formed general displeasure with ‘Delivery Metrics’ like ‘Velocity’, ‘Cycle Time’, ‘Lead Time’ etc. They really don’t have the ability to point to real areas of focus and tend to be opinionated by all those concerned. Ultimately, I have never felt like I have had a truly profitable conversation off the back of a ‘decrease in velocity’ Retrospective.

I have recently reflected on a growing concern between our Product Management team and that of our Engineers. I was hearing the classic warning signs. “We don’t feel like we are doing what we should be”, “We are waiting for Design”, “We are waiting for the next project to drop”.

As I stepped back and took in the big picture I realised something was clear. Our Product Management team was busy cementing in ideas and working on the solutions to best be articulated to our Engineering team and while they were busier than ever, there was no ability to force prioritisation from the Engineering team to say “We are waiting”.

Typically I have observed the influencing factors that lead to product feature prioritisation are driven by either, business strategy, customer demands or technical debt. Very rarely have I seen the ‘lack of work’ as a prioritisation tool. However, I have since discovered an operating metric that solves this problem.

I affectionately call it the Event Horizon.

‍A notional boundary around a black hole beyond which no light or other radiation can escape.
For me it's a point in a product backlog we should be terrified of.

Given the nature of product development is an exciting, stressful and chaotic time, the ability to understand the concept of an Assumed Backlog and a Realised Backlog are two vastly different things.

Assumed Backlog

An Assumed Backlog is that in which a Product Ownership team has fleshed out an idea, formulated the business case or ‘acceptance criteria’ for the idea, given it to the Engineering team to break down, estimate and deliver.

The Product Ownership team will then move on to the next item on their list, safe in the comfort of their ability to break down ideas, create the appropriate solution, get the technical ‘estimation’, sign it off. Pop it on the Backlog. On to the next thing.

Realised Backlog

A Realised Backlog is the amount of work that has been broken down and fully understood.

Points are appointed to chunks of work and committed to a future sprint/iteration.

There are some distinct differences between an Assumed Backlog and a Realised Backlog.

Estimating work is quite different to actually breaking something down to do it. The depth of understanding has to increase to enable your team to appropriately allocate work to a sprint/iteration. If any questions arise during the process of breaking something down, blockers or unforeseen dependency issues can arise which will derail a team’s ability to commit and deliver dramatically.

If any of these questions or issues require a shift in strategic decision making, this can truly stall the development of a product. Surfacing the severity of this can prove very difficult.

Event Horizon

Mathematically speaking, the Event Horizon is an agreed-upon ‘healthy’ backlog number of points committed to by a team, relative to the number of the team members who are working on it.

For example, if I consider a ‘healthy’ number of days of committed work it should be that of 4 weeks, per developer.

Simple math: In a team of 4.

4 x 5 (5 day working week) = 20.

I would assume if a team has 20 days worth of broken down tasks with estimates and it’s ‘ready to go’, they are in a healthy state to execute and deliver on their work. If however, I have a team of 4 people with 5 days in their Realised Backlog… there is an area of concern.

Not having a healthy Event Horizon can create areas of departmental friction from the feeling of isolation, teams feeling like their ability to deliver is compromised and overall motivation drops off dramatically when they feel they don’t have any ‘real work’ to do.

How I have seen this metric work.

It works to apply pressure in the right places.‍

Engineering Teams — This metric reminds teams that they shouldn’t only be thinking about the ‘now’. If the Event Horizon is tracking down, and they have work that they need to consider breaking down, this indicator reminds them that this is important and perhaps to bring in some necessary time over the next week to break some work down and bring the Event Horizon back into a healthy range.

‍Product Teams — This metric reminds the team responsible for prioritising product feature order of delivery that while they may be busy working on the next best thing, they may need to get some business or design approval to solidify feature clarity to enable the Engineering Team to execute.

‍Business Strategy — I have seen this metric enable conversations right the way to the top. It’s a simple way to understand ‘what’s happening on the ground’. It brings to light areas of roadblocks, strategic misunderstanding and a clear indicator if ‘things are running as expected.’

Event Horizon realities

The reality much like many Delivery metrics is that they can all be ‘explained away’. However. That said it has prompted some of the most valuable conversations we should be having when it comes to product delivery. Real data points to base our challenges on, and removing a personal ‘feeling’ from a situation.

The simple fact that a team has a ‘Realised Backlog’ in a healthy range does not necessarily mean they are working on the ‘right thing’. Their realised backlog could be full of work which isn’t ultimately delivering value.

Various stages of a Products lifecycle may demand or require a different size for its Event Horizon.

Overall, 2020 has produced many realisations in regards to the ability to deliver work. Finding a way to surface areas of focus without the need to ‘take peoples word’ has proved vital in these times.

If there was one thing I would share with Product Delivery teams this year, an Event Horizon would be it. A rather simple metric on paper, with huge value-add when implemented.