Just One More Sprint!?

In this post I am going to use a common scenario to highlight some key product development prioritization concepts. Specifically, we are going to dig in to the decision to stop one effort, and start another effort.

Do We Keep Going?

Let’s start with an example. When I draw it out below, you might say “this is a no brainer!” On some level it is, but stick with me.

Example…

I think a new workflow will generate $45k in extra revenue monthly (the Cost of Delay). We work for two weeks, and realize some very high percentage of that value ($42k/month). Should we “finish the project” (in this case add an additional option to the workflow), or should we stop immediately and take on new work?

Note how there is $3k left on the table…it is value yet to extract.

Comparing CD3 (For Work Done, and Work Remaining)

Let’s look at the CD3. CD3 is the Cost of Delay divided by duration (a week is 0.22 Months). Think of CD3 as the rate of creating value (when value is stated as value per time period, a time-based opportunity cost… our Cost of Delay).

The CD3 for the work so far (A) is 95.4. The CD3 for the remaining work (B) is 13.6.

Translated this means that A generated value at a rate of $95.4k a month, and B (if we continued the effort) would be generating value at a rate of $13.6k a month.

The Alternative: The Backlog Item

So let’s say we have an item in the backlog with a $40k/month cost of delay and an expected duration of 5 weeks. $40k/1.1 months = 36.3. The answer is pretty clear. Pull the item from the backlog and stop the effort. 36.3 > 13.6 (2.6x)

But, but, but…

The team is already working on this! How about the context switching? The team is on a roll! We should just wrap this up. Maybe a single engineer can keep working on it and we can split their time 50/50. Maybe…

Imagine compounding this type of thinking over all of your efforts. Think of the impact. Sounds crazy, right? But it happens ALL the time. It is an easy trap to fall into. Once a team is “on” an effort, there are all sorts of reasons given to keep going.

The Norm: A Single Big Batch

But let’s step back for a moment. Most teams do not deliver incrementally. Instead of delivering incrementally, they do something like this:

See how they wait until the end of week 3 to “release”?

They have a list of requirements / mockups / whatever, and they finish it all in one batch. Super Efficient! Let’s look at the super obvious problem first. By not releasing increments earlier, they are failing to move potential value through the system:

In our original approach, the first increment “earns” $14.5k in two weeks, and the second increment “earns” an additional $2k in one week. In the above example, by releasing only after the end of week three, we “lose” $16.k. That’s not great.

But the bigger problem is that by not releasing incrementally, we accrue risk…risk that it will not earn $45k/month, risk that the whole thing will not work when integrated, and risk that we might not discover some unlocked value and take the whole effort to an even better place. By releasing earlier, we can change course more quickly.

Let’s Do Both!

Often what happens is that the team rationalizes “doing both!” The first stumbling block is the cost of multitasking:

https://leanpub.com/managing-risk-with-agile/read

So by trying to do both, we’re losing 20% to context switching right off the bat. Veering from our example for a bit — because I’m lazy and don’t want to figure this out for our example — we see below that with Option #2 (doing both at once) we incur Loss 1 AND Loss 2:

So by optimizing for “going the extra mile” and “finishing what we started”, we’re taking on losses. The team is PAYING for the appearance of being proactive and not walking away.

A Full Time Engineer!

But the team will pull one last card…and that is the card of having a “full time engineer” dedicated to finishing off the original effort. This is a common ploy to circumvent the context switching argument (“hey, no one is multi-tasking!”). So something like:

• Finishing the project ($3k/month Cost of Delay) = Bill
• Starting the new backlog item ($40k/month Cost of Delay) = Mary, Lin, and Chili

While we’re at it, SOMEONE should stick with it. Why not Bill? And the rest of the team should get going on this new thing.

Consider a couple issues here:

• The CD3 of the remaining $3k CoD will be lower than 13.6, because Bill will be working alone. Originally it was slated for a week for 4 people, so it might take one person 3 weeks, or a CD3 of 4.5.
• Compare that to Bill working as a 25% contributor for the $40k CoD item slated to take five weeks. Individually he would be contributing to 25% of the 36.3 CD3 (0.25*(40/1.1)), or 9. Oh look…9>4.5!

So… having “just one person on it” does not improve the situation, no matter how you cut it. Even if Bill is a specialist, and only Specialist Bill can do the work, the fact remains that that the organization is permitting Specialist Bill to work on things that are significantly less valuable. That may be a structural problem, and completely outside of Bill’s control, but that’s the reality.

Conclusion

So what? What’s the point here.

• Deliver incrementally
• Avoid sunk cost bias
• Make economic decisions based on what you know today
• If you’ve extracted most of the value from an opportunity, then move on
• Be aware of the multi-tasking and FTE traps

Thanks!