Context

You’re on a team that is rewriting an existing system; you’ve spent time during Discovery to plan out the new UX, UI, and have estimated the core aspects of the needed development. There will be a new front end to for the people using it, along with new middleware and back-end services supporting it.

You’ve estimated it to be about eight months of work. You started a month late, and you’ve been asked to deliver the product a month early. So you’re down to about five months.

Since you’re replacing an existing application, feature parity and some new functionality is expected, and the time constraint is non-negotiable.

Classic waterfall. Since the current system was studied, you’ve estimated the rework, and given the time constraint, everyone is eagerly awaiting to see the app in production on the launch date.

However, something was learned in the first few sprints: the estimates are worthless. The assumptions have been identified as wrong, the development environment and the integration eco-system present friction, causing a lengthy PR process and causes rework and high lead-times.

Based on the team’s velocity, and the scant information in the few hundred stories that were mapped during Discovery, it’s evident that the team cannot meet the deadline.

Chicken and Egg between Engineering and Product

You inform your stakeholders, who are supportive, but ask you to re-estimate the delivery, so that they may reduce scope in order to meet the deadline. You’d rather ask them about MVP and then see how you can deliver it.

You indulge Product and start conducting re-estimation sessions with the team. Not very productive, because of those one-liner stories and unknown flow and implementation details. You spin your wheels while Product waits to hear from you.

You’re stuck.

The cone of uncertainty

The “Cone of Uncertainty” describes the reduction of uncertainty over time. Basically, uncertainty reduces as you get closer to deployment. You’re way on the left, where the cone is at its widest. Product is asking you to estimate when you’ll get to the very tip of the cone, way on the right. I don’t think much needs to be said that if we don’t find a different way to deliver, you’re in a stalemate, and as time goes on, it is being wasted on fruitless estimation instead of being put to use in delivery.

Thin slices to the rescue

The roadmap you’re following is “incremental” in nature. You wanted to prove parity feature by feature. So the roadmap takes your stakeholders on the journey as their customers experience it. Within the context of a feature, they move from one page to the next, and with UAT testing, they will validate that the implementation is correct.

Herein lies their need to get the estimates for the end date. Their expectation is to see the effort for each Epic because their product is the sum of those Epics. That makes sense from their point of view.

This is risky even though you’re in a “parity” development effort, where all the features are supposedly known in advance. The risk is that your product owners are flying blind in the sense that they are presented with outputs (tasks being completed) without the counterweight of outcomes (a pleasant and effective customer journey).

A more effective approach is “iterative” delivery. Each iteration will deliver working software that crosses multiple Epics, showing the end-to-end customer journey iteratively.

This is more effective than “incremental” because the slices will defined by Product, which implies that they are in an MVP state of mind. They’re basically tell you “I want to see this first, over that other thing”. It’s more effective for you as well, since you’ll be on the far right of the cone of uncertainty, since scope is much smaller in each iteration.

You’re now delivering to Value, not to Estimates

Your stakeholders will resist at first, since the conversation is focused on delivering value iteratively, and each iteration may deliver insufficient value to their customers. However, this delivery model relinquishes control to Product by allowing them to “cut” a feature-set they deem as production ready. In the “incremental” model, Product had no control till the end of the last increment. Using this approach, Product has control at the end of each “iteration”, which could be, if well executed, at the end of each sprint.

Conclusion

To me, this should be the de-facto method of delivering products, and books have been written about this since the introduction of Scrum and agile. Our Stakeholders sometimes veer off this course, influenced by design agencies that occasionally place the Whole Product and nothing but the Whole Product as their output.

Iterative delivery ensures Product due-diligence because it obliges us to question its outcomes at each iteration, allowing quick pivots and re-assessments, this time not of estimates, but rather of customer value.

Previous article Next article