Do you really need estimates?

That’s most certainly a tricky question. There are a lot of discussions around the topic since the agile software development community burst the bubble a few years ago and even though the #NoEstimate movement has more supporters every day (yeah let’s say every day, doesn’t really matter, the thing is it’s getting bigger) it still can be quite complicated to give a definitive answer to that question. So, what do you think?

Do you really need estimates and, if so, how to do them in a way that will really help the organisation?

No wrong answers here, I won’t lie I’m a big fan of #NoEstimate but hey, let’s talk about it 🧐

Why do we do estimates…and why it doesn’t work

If you think about it there are a few good reasons that come to mind. And wether you are working for an internal or external client they are pretty much the same.

Budgeting

No surprise here, to calculate a budget the equation is pretty simple (I know I know, it’s not that simple, but let’s consider the basics):

cost = activity duration * resource demand

Yeah, activity duration which is why we want an estimate. Seems fair enough, after all we do need to have some visibility. One thing though, the Chaos Report reports that 60% to 80% of estimates are off…Ok, we could argue about “off by how much”, but in the end it doesn’t really matter. Spending time on an activity that will give information that is that bad doesn’t seems like a good investment to me. Actually we are so bad at it that we keep inventing new ways of trying to get better and still fail. Let’s see the most common techniques:

NameDescriptionWhat’s wrong with that?
Guessing (don’t lie, we’ve all done it at least once 🤫)Well…like…guessingDon’t think I really need to explain this one
AnalogyCompare with past similar projectsTruly similar projects are rare (context, people, technology, knowledge…)
Expert JudgementConsult one or more expertsTheir opinion tends to be biased
They usually won’t be the one to do the work!
Complexity points and VelocityAssess complexity by comparing tasks
Check how you did in the past
Can help with forecasting a team’s capacity but for the estimate part we go back to guessing and analogy…
Three point estimatingUse Pessimistic, Normal and Optimistic estimate to get a better resultIf one estimate is usually wrong, add some more in the equation might not be the best way to improve the situation

One piece of advice, define what should have major impact on your business, that’s where you want to put your money. Reassess as often as it makes sense (with a preference for shorter iterations) and see if you need to go further or if the current state of things is good enough. Remember, the idea is that you will have a piece of working functionality at the end of each iteration.

Planning

You’ve done a whole lot of scheduling and by now you know how it goes:

  • Create a list of functionalities that you need and the associated tasks that must be completed (a WBS if you wish)
  • Analyse dependencies between those tasks in order to create a clear activity diagram (Gantt style, yeahhhh 😎)
  • Estimate each task, apply to the diagram and forecast dates

There, you have it, we need estimates now there’s no way around it! Hum, let’s see, I’ll stress this one once again:

60% to 80% of estimates are off

Chaos Report

So basically you will have to update your estimates along the way and take actions to correct any deviation (make sure the process is under control). If you have some experience you also calculated some contingency reserves that you can use in case of trouble.

Although usually that’s what will happen:

  • You do some estimates to forecast when everything should be ready
  • Things will not go smoothly (they never do) so you’ll have to adjust
  • You’ll estimates the remaining work and forecast new dates
  • Things will not go as planned…
  • Repeat until everything is done or we decide to stop

Ok, I’m being a little bit unfair here. It could work, and actually it does, but only when the tasks are highly predictable (manual repetitive work for exemple). Most of modern activities are not of that kind, they involve analysis, learning, adaptation and problem solving skills. Knowledge workers, by definition, are dedicating the most part of their time to unpredictable tasks.

The best way to know how much it’s gonna take is to actually do the work.

Once again focus on business value, what can you do right now to have as much impact as possible on your company’s activity and go for it, make things happen instead of trying to find out if they can happen!

Synchronization

We kind of talked about this one already as it is directly linked to the planning part. Based on estimates we plan the work and when it will be done. This helps in the synchronization of workers, each expert know when he will be needed (that is once the previous tasks are completed).

Just like planning has to be updated everytime something changes, the team synchronization does as well. The best way to manage the situation (at least in my experience) is to communicate as often as possible, in Agile@Scale I’ve used the Scrum of Scrum with very good results but one thing is for sure, having an upfront planning and synchronization plan based on estimates for all the activities involved in your project won’t do any good (and you know what, you don’t know all the activities involved in your project until you start working, I know shocking right?).

One last observation that comes up quite often: what about marketing communications? Let’s say we are launching a new campaign, we need to inform our clients and to do so we need to know when the necessary tasks will be done. It’s understandable and the consequences could be pretty bad for the image of the company. If you can wait last minute for the announcement you don’t really have a problem. If not, well stay close to the persons involved in completing the work and reassess as often as needed. Visibility will get better everytime a task is completed and you can reorganize priorities based on updated information (maybe change the scope in order to make it to a specific date), it will still be better than planning your marketing based on a schedule that will turn out to be inaccurate.

Just because we’re used to it?…

We are, all of us! We plan for everything, shopping, vacations, dinner, weekends, who is going to walk the dog at 7am during the winter when it’s -2°C outside (spoiler alert, it’s me)…personal life or professional life it’s the same. Estimating what we’re going to do, how and making plans based on it gives us a warm feeling of control and comfort. And even though I strongly believe that it is not efficient I sometimes have difficulties explaining it to others. How do we do if we don’t know when it’s going to be ready? 😱

The thing is, something is going to be ready. And if we do our job correctly it should be what brings real value to the company. Yes, we might not do all of it and yes, we will change plans along the way but what matters is the result right? So let’s make sure we work on the most important business needs at all time.

Image result for minions

Even science agrees

It’s a gambling game, this should be clear enough at this point, most of the time we don’t have all the information (even when we think we do). And we are bad at it, like writing a text message on your mobile while walking on your hands and wearing ski gloves bad…There are a few laws about it and the following ones are my favorites:

Work complicates to fill the available time

Parkinson’s law corollary

As human beings we are very good at complicating and over-analyzing things. I find this law particularly accurate, it is one of the reasons we sometime have complicated solutions for simple problems.

It always takes longer than you expect, even when you take into account Hofstadter’s Law

Hofstadter’s Law

This law kind of complete nicely the first one. Even for very simple tasks you will definitely need more time that you thought (you know the saying: ladies, when a man tells you he’s going to do something he will, there’s no use in reminding him every 6 months…).

If something can go wrong, it will

Murphy’s Law

It’s not pessimistic but pragmatic, and if you’ve been a developer for some time for exemple, you know that your code will never work correctly the first time you try it, you always forget something while doing it…better to assume this from the beginning, act accordingly and avoid unpleasant surprises.

Oh, and let’s not forget about the Planning Falacy, like I said, it’s nothing new.

So, what do we do? 😬

Focus on business value, that’s what we are working for and every initiative and action should be aligned with that. If something doesn’t add any value why should we do it? And if we accept the fact that most estimates cannot be trusted the real question should be what is our top priority, not how long does it take to do it.

The real question should be what is our top priority, not how long does it take to do it

Something important here, dealing with technical debt or spending time on a PoC to learn a new language for exemple are adding business value. Technical debt will slow down your business sooner or later: instability of the platform, higher complexity to develop new functionalities…and much more (there’s a link to a paper on this subject at the end of this article if you’re interested ⬇️ and a rapid google search will give you plenty more).

Now if you really have to do estimates, use macro ones. That is don’t try to get too much into details. It will still give you an idea of what you’re getting into without too much investment (extreme quotation is your friend).

Keep It Stupid Simple: short term objectives for medium to long term goals, stay focused on delivering value as fast as possible, short iterations eliminate risk, estimates don’t (well, not so much)!

If you want to make God laugh, tell him about your plans

Woody Allen

A few links

Did you like this article? Show it

Leave a comment, like on LinkedIn 👍 and share! Your help and feedback is important, it helps me to learn and keep improve, thank you 😀

Comments are closed.

Blog at WordPress.com.

Up ↑

%d bloggers like this: