The Art of Creating More Value With Less Work

In Zen and the Principles of Construction, a landscaper, an architect and a constructor quarrel over which guiding principles to use to build a house. They can’t agree on whether it should be philosophy, mathematics or experience. In the end, the stars of the Summer Triangle provide the answer: they need all three.

The same applies to software development. Development frameworks can give us philosophical guidance, and experience is as invaluable as in any other trade. What we need more of in software development though, is simple mathematics.

A case study

Let’s say your team of three is in the midst of a two-week, 80-hour sprint with 30 backlog items.

Three backlog items are of particular value, because they represent a new feature with an expected $500,000 return in the next 12 months.

The remaining 27 items do not directly support the sprint goal, but have been added as “fillers”, to keep developers busy when there’s nothing else to do.

While the sprint is ongoing, senior management expresses concern about the lack of progress. Quite why is not clear, as they agreed with the sprint goal, and the development team is working at full capacity.

What is senior management so worried about? Let’s try and see things from their perspective.

The management’s point of view

Whereas what you see is the development team working hard, senior management is keeping their eyes on how fast the backlog items are moving on the project board from “to do” through “doing” to “done”. And despite the team’s efforts, tasks don’t seem to be moving that fast.

Isn’t that strange? The team is working so hard! Could mathematics shed some light on this paradox?

Enter mathematics

In order to understand the apparent slow pace of development, let’s measure the ratio of value-added time versus idle time per backlog item.

The development team is working with three people on 30 items during 80 work hours. With 3 people · 80 hours = 240 available work hours, each task takes 240 / 30 = 8 hours on average to complete. Given an 80-hour sprint, any 8-hour task is sitting idle for 72 hours.

Think about it. In this active, high-priority sprint, with everybody pushing themselves to their limits, sprint backlog items are sitting idle for 90% of the time.

The sprint goal involves a 12-month, $500,000 opportunity. This means the business loses $500,000 / 52 weeks = $9,615 per week that the feature is not available. We call this metric the Cost of Delay.

Now it becomes clear why senior management is so concerned! The clock is ticking, idle time is 90% per task on average, and time is chipping away at their $500K.

Meanwhile the development team, in their mistaken belief that working to full capacity equals maximum economic return, has actually done the business a disservice with those “filler” backlog items. Especially in a phase-gate process, in which all code needs to go through code review, branche merging, and deployment, each “filler” backlog item clogs the development pipeline with queues, defects and rework.

This is why we need mathematics in product development. It can tell you when, in order to get a better return, you need to schedule less work.

Would philosophy and experience have told you the same thing?