Introduction

I am a big fan of the #noestimate movement. As Allen Holub would say, “we just finished some work without using any estimates and things were fine”.

The reality is that many companies want you to give clarity on when a piece of work will be complete. The most common way of doing that is through refinement, breaking the work down and extrapolating a date. Giving a date is a trap that people fall into as they provide a week on work completion, and the recipient takes either the first day of the week or the last day of the week when they expect to see something in production.

What happens when you don’t hit the date?

When you don’t meet the expectations, you will receive feedback. Other actions could likely have been planned on the back of the date you provided. The marketing department might have planned a campaign using the date you provided, eeek, The next time. You add padding to your estimate. This padding will compound over time as everyone in the system could incorporate padding, thus making it a slow system overall.

How to avoid the trap

Learn how to give a better estimate. I do not mean you need to provide a more accurate date but know what makes up an estimate. That better estimate will helps the people receiving the estimate judge their follow on actions in a more informed way.
The core of an estimate is the following

• Scope
• Range of time
• Confidence

Scope

What does this feature do? Explain using plain language the outcomes the end user will achieve. An example would be, “When a user clicks run, it calculates the final total and displays the result in a modal dialogue.”

Range of time

Never provide an exact date. Always give a range. The smaller the scope, the more narrow the range can be. The more undefined the scope, the more extensive the date range should be.
If the scope is to land a man on mars, the range is in multiple years. If we stick with the “calculates the final total” and understand clearly how that is calculated, we can go for a two-week window.

Confidence

Confidence is the probability of you being correct about the scope and time range. It is to consider that you may not be aware of the total delivery of the feature. Maybe you need to make an infrastructure change, which happens only once a month.
The language should be, “I have 80% confidence that this will be done.”

Putting it all together

I have 80% confidence that we will have the following “When a user clicks run, it calculates the final total and displays the result in a modal dialogue.” in the first two weeks of August.

What happens after the initial estimate?

You are not done yet. The further out the estimate is, you should add the caveat that after working on the problem and gaining a greater understanding, you will come back with a more refined estimate.

Epilogue.

Estimating like this is a way of providing clarity on when features will be in production. There are others. Future posts will consider alternatives to estimates when giving clarity.