Blogpost

Gut feeling estimates

How does one get "rough" estimates regarding the effort needed to fulfill some kind of work package? The answer is: Based on gut feelings. Estimations must be done by the person who will do the work. The estimated result will belong to one of the following "natural" ranges:

minutes, hours, days, weeks, months, quarters, years

Meaning

  • minutes: 1 to 60 minutes
  • hours: 1 to 24 hours
  • days: 1 to 5 days
  • weeks: 1 to 4 weeks
  • months: 1 to 3 months
  • quarters: 1 to 4 quarters
  • years: 1 to open end

Usage for receiver (the one who asks for an estimate)

For instance, if you get the estimate "day", you know it'll probably take one to 5 days untill the work is done. Thats it. Do not ask for more accuracy. Just accept it.
It is up to the receiver to manage the "risk" which amount of days should be used.
This will lead us to get (good!) estimates very fast.

Especially for longer ranges (starting with "week") it is important to ask again, at least one time e.g. after about 50% of the original estimated time has gone past. This allows us to use the developer's experience, which typically grows as we work on the project. It is good to plan such an estimate-refinement from the beginning on, together with the developer.

Usage for worker (the one who will do the work)

  1. If you genuinely have no idea, ask for a short time box ("minute" or "hour") to do a walkthrough of the work. It is important to "time-box" this.
  2. Walk through the units in mind, for instance: Is it possible in minutes? No. In Hours? No. In days? No. In weeks? Maybe => estimate is "week".

Prerequisites

  1. Trust.
  2. Networking tool to record Shared Understanding. Every participant has read and write access to it. The estimates must be visible there.

Motivation

Even in an agile development, the owner will ask for estimates. This is something a developer has to accept. Most developers (or all!? ) do not like estimates, and this is not without reason. It is not because they just "do not like it": More often it is, because they want to do it good. However they (especially the experienced developers) know, it is not possible, or at least very time consuming, to do so.

Since agile development does not correspond to having no plan or road-map, developers are required to give estimates. So, what can be done?

One option dev-teams commonly choose is to use adjectives like "high", "medium" and "low" or colors "red", "yellow" and "green" to signal a clue of effort size. This is meant to be useful in order to get the mentioned "vague" estimates, to reflect on previous inaccuracy or to prevent other people from misunderstanding certain time frames. However, the issue is, that it isn't obvious for all participants what these units mean (e.g. think of new team members). What does it mean for a task to be regarded as "high"-effort? It is required to maintain some definition of these units. These kind of units don't work in favor of effective communication, instead they complicate it reasonably often. Contrary, if I get a statement like "This will take weeks" I know what it means. So why not plan with it?

References