Are we going fast enough?


During the past few years our industry has been transitioning from traditional waterfall to agile software development, the panacea to all our problems.

This has been partly driven top-down by management seeing success in other projects, and thus as a way of producing a quick fix in their own teams and processes. There has also been a strong groundswell of developers craving greater autonomy and freedom in their work.

How well are we doing?

Within these new agile processes there are no Gantt charts, or top down imposition of fixed scope. Instead we use suitably arbitrary measurements of progress such as Cycle Time or Story Points.

This arbitrariness is deliberate to some extent – after all every piece of bespoke development is by its very nature unique, and the teams that are assembled to deliver this development will most likely not all have worked as a group before.

When the development team provide Story Point estimates they are meant to reflect both the effort and uncertainty around the story under consideration. The estimates only have value relative to each other – a 20 point story for one team may be a 5 point story for another team.

That’s not to say the second team is 4 times as quick, they just have a different scale. In some instances, depending on where the story sits on the complexity scale, it may not even be possible to estimate parts of it.

On the surface, having a single number for every story allows us to understand how well the team is doing by calculating how many points were done for each Sprint. We have several mechanisms for optimising and improving performance via pair-programming, retrospectives etc.

It also gives something tangible that Project Managers and senior stakeholders can measure and become excited or disappointed about as the numbers go up and down.

Will it make the boat go faster?

“Will it make the boat go faster” is a fantastic story of the Great Britain Men’s Rowing Eight and how they optimised everything to win gold at the Sydney Olympics in 2000. It focuses on finding a single goal and building and evaluating all activities around that goal.

You find this approach commonly applied in call centres, medical triage times or any activity were there is a single metric whose throughput is paramount. It’s quite often subconsciously applied to software development teams as well, including those following agile processes. In this case the desired outcome can be more points or faster cycles.

This is where an agile project, focusing on single metrics, can start to unravel.

The focus on a single metric can lead to story point inflation or story fragmentation where the development team, in order to meet ever increasing targets from management, begin to misuse and game the point or story size in order to keep everyone happy.

Velocity is a very common measurement of progress in a Scrum project and Ron Jeffries (one of the original Agile Manifesto signatories) wishes he’d never invented it!

What’s the alternative?

We have to remember that User Stories themselves are thin developable slices of features of a system. It is these features that work together to provide capabilities which actually let a user (the “As a …” part of the title) do something meaningful with the software (the “In order to …” part of the title).

The delivery of stories and their associated metrics (cycle time/story points) can be quite far removed from realising the final business value of the system. Delivering 90% of the stories for the essential features of the system will effectively leave you with little business value as no feature is 100% complete.

We need to find a way of moving away from a single metric as a measure of progress on an agile project. Completed story points can be great as an indicator of effort and risk, or even as an indicator of capacity, but it’s a poor proxy when considering progress.

Instead we need to consider mechanisms for measuring contribution towards business value, and we’ll be exploring some of these approaches in later posts.