Take back control of your development, without the illusion of estimates

• Agile and Lean
• CEO
• Best of

Letting Go of Estimates

Whether you want to hear it or not, no one can estimate anything because the uncertainties are so great: There are technical uncertainties, which are all the more significant when technical debt is out of control; but, even before the technical uncertainties, there is the functional unknown, which we resolve as we design the application and gather user feedback.

In other words, estimates are made before we know what to develop. Reread that sentence slowly—it makes no sense. Yet that’s exactly what we do every day, and that’s precisely the root of the problem. Example: “I want to develop the MVP in a year—is that feasible?” Any reasonable person would object: “I have no idea—it depends on what you want to put in it.”

On the other hand, estimates are a huge game of deception, because they’re taken at face value and become binding. So we protect ourselves by building in excessive buffers, or we say what the client seems to want to hear, and come what may.

If you ask me, it would be better not to base your schedule too heavily on this, especially since estimation errors increase with the estimated workload. From 25% for one month of work (design and development), the error rises to 50 or 75%, sometimes more, for an initial estimate of one year. If this shocks you, understand that every software project is unique, and that the unknown lies first and foremost in the choice of what needs to be developed—well before considering any technical aspects.

When the unexpected is the only certainty

Unfortunately, the picture doesn’t end there. In fact, you don’t even always know how much time you actually have, or what resources are available to you. You may indeed plan to deliver your MVP after a year of work, but still consider what might happen:

• Competition forces you to deliver earlier than planned—after 6 months, for example;
• Someone leaves the team, which is all the more problematic because that person holds all the knowledge (high “truck factor”);
• You’ve overestimated your ability to be productive: 8 hours of work per day rarely equate to 8 hours of productive work.

These “unforeseen issues” will consistently put you in a bind if you approach the problem solely from a time perspective—because you’re going to run out of time.

So what can be done? Are you doomed to put up with it?

The answer is a categorical “no.” Granted, you can’t control the uncertainties mentioned earlier; granted, estimates are a futile attempt to regain control; but you can, on the other hand, influence the course of events by breaking down the work to be done into small pieces and setting clear priorities—every day.

In other words, your only solution is to always have something up your sleeve, just in case. Like the Boy Scouts, you must be “always prepared.” What does that mean?

Take back control with a detailed breakdown and clear priorities

If you have a year ahead of you and have to wait six months to finally see how the work is progressing, you’ll likely lose some sleep. Your problem is the tunnel effect: when a car enters a tunnel, an outside observer knows nothing about its location until the car emerges. In other words, until everything is done, it’s as if nothing has been done.

So you want shorter sprints. One-month sprints would already be better, but why not aim for the best and consider one-week sprints, or even shorter? The beauty of it is that it’s entirely up to you—you can break down the app’s features into smaller features, which we’ll call User Stories.

This breakdown must necessarily add value for the user: breaking things down into technical tasks is the main pitfall to avoid. Example: Your front end is perfect, but the back end to go with it isn’t ready yet. That’s of little use to you: you’re pressed for time and have nothing to deploy. It would be better to consider a smaller feature and do “a little” front end and “a little” back end.

A User Story must therefore be able to go live and provide value to your users, even if it’s very little. And in fact, it’s better if it’s very little, because you can always do more later, but at least you’ll already have something to deliver in case of unforeseen circumstances.

As an example, let’s consider a CRUD (Create / Read / Update / Delete) application—that is, a database of items without much management complexity. Think of Marmiton (cooking recipes) or the SPA website (animals awaiting adoption). If you were to set up such a site, how would you break down your work?

• Create first, then Read: allowing an item to be created without allowing it to be read is of no use to anyone—it’s the false good idea!
• Create and Read, simultaneously: that’s already an improvement—we can create and read items. The added value is clear, but on second thought, we can do even better;
• Read first, then Create: surprising, but yes, because we can temporarily make manual database insertions before building a graphical interface for it. A true first step toward Agility.
• And we could go into even greater detail by breaking down the Read feature: start with a simple list and gradually add a master/detail pattern, filters, sorting, full-text search, pagination, etc.

Conclusion

So make it your goal to have something to deploy to production as soon as possible—even if it’s not everything, even if it’s not ideal—it’ll still be better than nothing. Prioritize aggressively: you want A and B, of course. But which one do you want if you only have time to do one?

As you can see, you can’t win against time. Breaking your work down into small tasks and prioritizing on a day-to-day basis is your best weapon for regaining control—and, at the same time, accepting a share of responsibility for how things unfold.