
Ask HN: Best practice for estimating development tasks? - pacifika
Would like to see a list of resources that would be useful to help improve estimating skills.. books, resources, methodology etc.
======
mindvirus
Not a list of resources - but my rules (to myself) for estimating are below.
My personal bias is that I really dislike under-estimating, and I typically
over estimate how long tasks will take (by design) - but usually it's pretty
close (i.e. not an order of magnitude off).

1\. Usually, the smallest unit is a week. When people say something will take
a day, it's usually wishful thinking - they forget about meetings, other
commitments, etc.

2\. Think about what "done" means for individual tasks when estimating. Often
more junior engineers will give estimates where "done" means the code is
submitted to source control - but really think about the work that it'll take
to get that code into production. Testing, configuration, documentation,
monitoring/metrics/alerts, etc. I think a lot of under-estimating comes from
this, where the estimates are just for writing the code, and all of the other
stuff comes either as a scramble at the end, or a ton of time to actually
launch as tons of bugs and missed features are discovered late in the game.

3\. Think in latency and throughput. Estimates typically have both baked in -
if something takes a week of "at-keyboard' time, it might take a month to get
done because of other commitments. Both estimates are important.

4\. Think in probability distributions rather than absolutes. I usually set my
threshold around 90% confidence - i.e. my estimates are based on where I am
90% confident I can have something done. When you think about how long
something takes, if the stars align, a 10 day task might take 5 days, but if
things go wrong, that 10 day task could take several months or more. Things
can only go a little bit better than expected, or a lot worse than expected.
But when people make estimates, I think they are often biased toward the
"stars align" case, and forget about this fat tail.

5\. With team estimates, add a friction value to longer term estimates to
account for vacations, sick days, distractions, etc. Usually around 30% seems
to work. So that one month task (20 days) I plan for it taking 20 * 1.3 = 26
days.

6\. Work backwards from the end goal. This forces you to factor in things like
testing and productionalization. This also helps with coordination too, as you
can figure out when to parallelize tasks to get to the end goal.

7\. Write estimates down, and go back and reflect. When something that you
thought would take a week took a month, sit down and really think about why.
This will help you recognize and refine your biases.

------
JasonSage
My go-to reference for this is Evidence-Based scheduling. In a nutshell, the
methodology is to NOT change how you estimate—why fight the behavior you're so
accustomed to—and instead measure how past estimates differed from actual
delivery time. Over time, the model you train can become very accurate at
estimating and—importantly—does not require you to do anything different than
you normally would. Link [0]

Now here's the other important thing! You must realize that there are multiple
types of tasks and they require different kinds of estimates. You can use the
Cynefin framework[1] to categorize problems into one of a few domains:

For problems in the Simple domain ("known knowns") you can give an exact
number on how long it will take, because the solution is known to you and
there's absolutely no uncertainty.

Problems in the Complicated domain ("known unknowns") have some up-front
questions that can be answered, and you have the capacity to answer in the
requisite time—these problems you give an estimate on, because you don't
literally know how long it will take but you have an idea.

Problems in the Complex domain ("unknown unknowns") have a high amount of
uncertainty. You must at least start work on them in order to fully understand
the problem and the realm of possible solutions. Use Agile here and let the
client know that there's multiple steps involved and it's very hard to give a
good estimate. Give the client the estimate for the first step and let them
know you'll be able to get back to them with more information. If they
_require_ an overarching estimate, think really big so when those "unknown
unknowns" show up they can't bite you in the ass.

0: [https://www.joelonsoftware.com/2007/10/26/evidence-based-
sch...](https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/)

1:
[https://en.m.wikipedia.org/wiki/Cynefin_framework](https://en.m.wikipedia.org/wiki/Cynefin_framework)

~~~
pault
I'm my experience, if the client insists on complete estimates before the
project is started, you should find another client.

~~~
tonyedgecombe
I noticed while I was contracting the more the client pushed for a fixed price
the more likely there would be problems with scope creep.

------
romenrg
Great topic. Given the fact that we, developers (as humans), are terrible
estimating in time tasks with a high degree of uncertainty (most cases in
software development), the most effective way I have found after many years in
the field is using velocity (based on effort points) as a (project-dependant)
predictor, while applying Scrum, as described in the following article in
detail:

"Why Asking Developers for Time Estimates in Software Projects Is a Terrible
Idea and How to Bypass It With Scrum":
[http://www.romenrg.com/blog/2015/09/28/why-asking-
developers...](http://www.romenrg.com/blog/2015/09/28/why-asking-developers-
for-time-estimates-in-software-projects-is-a-terrible-idea-and-how-to-bypass-
it-with-scrum/)

------
bungie4
Well timed.

I just had my annual performance review, and it was brought up that my time
estimates are consistently 'off'. The actual complaint was ridiculous because
I typically get my work done faster than my estimate.

So, you order 'food' at a restaurant, and they bring you a nice filet mignon,
and you criticize them for not bringing you leftover chicken.

Being forced, in a corporate setting, to come up with a time estimate without
any information other than a 100,000 foot view of a project, combined with
ongoing commitments, interruptions, meetings, conference calls etc is
absolutely ludicrous. So I tend to estimate high. But not overtly high. Some
projects still run over (usually owing to not having anywhere near enough info
to estimate). These are not mentioned during the review, only those that were
delivered significantly under.

Then to be criticized for over delivering during performance reviews at year
end... Anybody looking for a programmer with 30+ years of experience?

~~~
snarf21
I think it is reasonable to push back and ask for more requirements. If they
say that they don't exist yet, estimate it will take 6 months. When they
accuse you of being unhelpful, restate that at present you don't have enough
information to make any kind of reasonable ballpark estimate let alone
something for them to put in their awful gantt chart.

If that path won't work, then I'd tell them that I need two days to break it
down into all the tasks that I _think_ I'll need to do and then give them an
estimate after you do that investigation.

------
hugs
The problem with estimates is that it's easy to install (and easy to estimate
the time involved installing) a new air conditioner (or water heater or other
applicance), but it's hard to estimate how long it will take to design/invent
a new air conditioner, etc.

In software, the frustration between customers/management and developers comes
from this misunderstanding. They think they're asking for a simple install of
a thing (which has known risks), but they're often really getting the
invention of a brand new thing (with unknown risks).

So my solution is to only give high-confidence estimates for things I've
already done once. (e.g. I _know_ it takes me 4 hours to assemble and ship one
of my robots. I know because I've done it 100 times. But I have no idea how
long it will take to design a new robot using unfamiliar parts from scratch.)
But I do try to clearly point out where things are "installations" and where
things are "inventions", with the appropriate margin-of-error for each kind of
task in the estimate.

------
chrisan
Breaking things down into smaller parts will help you estimate better.

Also, sadly, just getting more experience will improve your estimating. Don't
expect to be very accurate when you start. Most young developers, myself
included, think "oh that will be no problem at all" and lowball everything.

There is a good question on StackOverflow to check out
[https://softwareengineering.stackexchange.com/questions/648/...](https://softwareengineering.stackexchange.com/questions/648/how-
to-respond-when-you-are-asked-for-an-estimate)

~~~
marcus_holmes
The usual problem with this is that we tend to estimate based on difficulty,
not effort.

Building 10 web pages is "easy" because we know how web pages work, no
problem. So we allocate half a day per page because it's just HTML, right?

Designing a user interaction path through 10 different application functions
isn't hard, but it takes a lot of communication and effort. Half a day per
function is a tiny fraction of the effort required.

------
tobltobs
Take your final estimation (whatever method you use) an multiply it with 2.

~~~
collyw
Multiply by 5.

~~~
avaika
And add 2 weeks. Just to be on a safe side :)

~~~
maephisto
And finish the sentence with "...probably"

~~~
godelmachine
Finishing the sentence with "probably" would be a bad idea, methinks.

~~~
eaphis
How about, "if all goes well" instead?

~~~
godelmachine
Much better :)

------
louisswiss
The classic solution is make a rough estimate, double it, then increment the
unit. Eg. rough estimate of 3 hours becomes 6 days.

I try to avoid working with people/teams where I'm forced to make this kind of
estimate. It's a great selector.

------
charls_Aws
Have been doing this for about 8 years. As others have mentioned here is
something you can follow:

1: Break tasks into as small as you can, say a few hours to a day.

2: Add time estimates for writing the main code, writing tests, doing
integration test and code reviews separately.

3: Also take into the account the time which might be wasted to unknowns,
things which you know needs to be done but do not have much idea on how you
would do that. One way to refine this would to be to talk to other developers
who might have some experience doing this part of the task.

4: Account for 'unknown unknowns' these are the tasks which will show up but
you can't really predict these upfront. Any software developer who has done
commercial software can tell you that for every project 10-20% time is used in
this which we did not even anticipate. These things always show up.

Now if you break down tasks into these parts, add up the time and then add a
'buffer' say 10-20% on it and give your estimate. I am sure you will face
pressure to reduce estimates, but having a break up allows you to provide some
support to the numbers you come up with.

Hope this helps.

~~~
blooo
This approach seems very time consuming at first, but the first step itself
starts to show you the ROI on the invested time.

When I start breaking down a task into smaller pieces, I often come across
things I had not thought of when just thinking about the monolith. "Oh, I'm
using X here, but where am I getting X from? That's another task."

------
pawelkomarnicki
Programming is a creative task, it cannot be strictly estimated. Somebody
mentioned Evidence-Based Scheduling, and it's the best way to estimate ("doing
X is similar to Y, and it took Z hours, so it will be unspecified amount of
time, but probably around Z hours"

~~~
mrweasel
>but probably around Z hours

But maybe significantly longer. Programming is a little special, because if
you done it before, then doing it again takes no time, you just reuse the code
from last time. So you're always doing something you never done before, or at
least in a different context.

------
yjftsjthsd-h
A rule, forget the source: take your estimate, double the number, and increase
the unit. Think it will take 2 hours? Tell management/customer 4 days.

~~~
pliftkl
No. Estimates have a very real purpose, even beyond communicating to managers
and customers (whom you should be honest with anyway). Our estimates are used
as a team to figure out how much work we can commit to in a sprint. They are
also used to determine if you are getting better at things. When we start a
project, we don't really have a code base, and many tasks are "new". I expect
my estimates to be really wrong at first, and then when I'm implementing
things that are very similar to what I've done before, I expect those
estimates to get better. I can't really measure that if I'm producing bullshit
CYA estimates.

~~~
dllthomas
My interpretation of the advice was not that it's intended to mislead, but
that it's expected to be more accurate than your initial guess.

------
segmondy
There's a book Software Estimation Demystified by Steve Mcconnell

~~~
skrebbel
Seconded, it's a good book. It doesn't only cover how to estimate but also, to
some extent, whether to do so. Finally, it allows you to get very far just
reading the first few chapters, a must-have for technical books IMO.

My biggest takeaway from reading this book is that making point estimates is
hard and often unnecessary. Saying "umm somewhere between 2 days and 2 weeks"
is a much better response in many situations as it conveys to the listener
that there's a high degree of uncertainty.

------
lmm
Don't overthink it. Do only as much estimation as you need, not more -
relative estimation ("project A will take twice as long as project B" ) is
often much easier than absolute estimation, and is often all that you need to
base decisions on.

------
IgorPartola
If you’ve done the task before, double the estimate. If you’ve never done it
before, 10x the estimate. Break tasks down to granularity of 1-8 hours. No
more than that. Estimate time != real time because life, meetings, other
projects.

~~~
GrantSolar
>Break tasks down to granularity of 1-8 hours. No more than that.

I do this for sub-tasks that are relevant to myself only (for example, "create
function to do X"), but my minimum estimates are 1/2 a day (in extreme cases
like a 1-line fix) or 1 day for anything that goes to a manager.

------
igvadaimon
I think this kind of thing comes only with experience. Large amounts of
experience.

There are simply too many factors to consider. The team, the client, the
project.

I usually follow this rule: take the worst case scenario estimate and then
double it :)

------
jonheller
E = (a + 4m + b) / 6

where

a = the best-case estimate m = the most likely estimate b = the worst-case
estimate

That's my favorite, called Three-point Estimation:
[https://en.wikipedia.org/wiki/Three-
point_estimation](https://en.wikipedia.org/wiki/Three-point_estimation)

This is also a great article on the challenges of estimating development
tasks, from the Basecamp blog:

[https://m.signalvnoise.com/running-in-circles-
aae73d79ce19](https://m.signalvnoise.com/running-in-circles-aae73d79ce19)

------
jdmichal
Stop estimating, and use previous efforts as evidence of capability to perform
future work. The basic idea is to use previous projects as a basis for a
distribution, use Monte Carlo simulation, then use whatever quantile you're
comfortable with to "estimate" the new project. You can even use multiple
quantiles to provide a range, if you care to.

[https://www.infoq.com/articles/noestimates-monte-
carlo/](https://www.infoq.com/articles/noestimates-monte-carlo/)

------
oceanghost
I have personally had good results with Wideband Delphi, however with a few
tweaks.

1\. Instead of iterating until there's complete consensus, take the min and
max of each of the subtasks and use them as follows: The sum of all the min's
is the absolute best case hours estimate. The sum of all the max's is the
absolute worst case hours estimate. 2\. To project a completion date from the
raw hours, you need to estimate how many weddings, deaths, vacations,
pregnancies etc. your team might have-- this is absolutely a guess. 3\. Assume
an engineer works no more than 80% a day-- he will take coffee breaks, answer
e-mails, meetings, etc. 4\. Know your engineers and apply individual
efficiency metrics to their tasks. Some guys will work slowly but their first
version works flawlessly. Some guys will race through things only to have
their code not pass validation later. Most people are somewhere in the middle.
5\. Don't forget time to automate test tools, builds, deploys etc. These are
huge time savers. 6\. If doing hardware+software projects, integration will
take way more time than you possibly think it could. You will hit at least one
dastardly bug in your OS, hardware or silicon. 7\. Give estimates as
probabilities of completion, not hard dates.

 _NEVER_ give an off the cuff estimate for anything non-trivial. You will be
held to any utterance you make. The correct answer to a request for an
estimate is, "I don't know."

If your management won't allow you to make detailed estimates, or won't
provide detailed enough design documents, specs, they are not serious
individuals and don't deserve a serious answer.

------
IMTorg
(shameless plug) I'm the creator of:
[http://scrumsaga.com](http://scrumsaga.com)

It takes metadata from your github repo, and provides effort / time estimates
from your previous tasks. Actually, it does alot of things, but the general
goal is to facilitate quick understanding and communication of complex
systems.

Currently, in beta. Let me know your thoughts.

~~~
pliftkl
First thoughts: don't link to a bunch of lorem ipsum based documentation from
your home page.

------
chrisweekly
This "hiking trip" analogy[1] is about helping explain "why it's hard", rather
than providing a best practice, but hopefully still worth sharing.

[1] [https://www.quora.com/Why-are-software-development-task-
esti...](https://www.quora.com/Why-are-software-development-task-estimations-
regularly-off-by-a-factor-of-2-3)

------
matt_s
One agile methodology is to use fibonacci numbers, I think its called planning
poker out of scrum. Then you assign the numbers to tasks/tickets with the
bounds being:

* 1 being easy, doable in a day

* 13 being too many unknowns, have no idea how long

This works for estimating the size/scope of work, but does not really work for
estimating time. Estimating time is mostly pointless as there are unknowns
that come up, even on small tasks, especially dealing with existing systems.

What this does provide if you use the numbers consistently is a team velocity
for planning purposes. After completion of work you (as PM) can go back and
look at two or four week averages of point velocity. Then future work point
estimates can be grouped and rough completion timeframe estimated based on
past velocity.

If you want to get better at estimating your own tasks, like if a PM is asking
"pacifika, how long to do $X?" the best way is to just do more development
work and you'll be more confident with your estimates. Working at a place that
expects unknowns and doesn't berate people for "missing a date" is a good
thing.

A way around lots of planning/estimating time is to do Continuous Delivery.
Breaking up work into smaller tasks and putting them into production when they
are ready. Even if this means temporary work just to put something in
production ahead of other parts. Its super simple to delete temporary things
later.

Having the confidence to run tests and deploy small changes to production
whenever you want to alleviates a lot of waste, from a lean perspective, in
the planning cycle. No meetings to coordinate lots of moving parts, no 3
releases per year with a weekend long release that people have a 50/50
confidence factor in. A simple deploy when ready.

------
cpfohl
My boss wrote up our way of communicating those estimates:
[http://www.apsis.io/blog/2016/04/18/communicating-
estimates](http://www.apsis.io/blog/2016/04/18/communicating-estimates)

As a rule we have a few techniques that have produces our most accurate
estimates:

One: since we're a team we get more than one person to estimate independent of
each other, then we talk about it. If you're solo, you can still have a
trusted friend do the same.

Two, we measure the uncertainty: client says they have a file ready to go once
you sign. Client hasn't designed the login page. Client has spec but like most
specs it's under specified. Each piece is going to take time to unravel. We
try to make sure we look at that uncertainty when estimating.

Three: we always remember that project management takes up tons of time. Even
if there is an outside manager you have to manage your workload and
communicate to your client. Make sure you factor it in.

------
loydb
I hate to say it, but the best way to learn to estimate dev time is to do a
ton of dev work and learn by bitter experience.

~~~
crispyambulance
Yes, and developing the courage to say "no" to project managers who prompt for
"off-the-cuff" estimates.

------
bane
Once I had a very difficult customer who insisted on extremely precise
timelines when we were doing some unknowable research. I finally got them to
agree to "as fast as possible and no sooner".

~~~
pc86
How much of an "Asshole Surcharge" did you add to the project?

~~~
bane
Not enough.

------
fiftyacorn
I normally look at the task and have a min of 2 hrs -

> 2 hrs - Simple Tasks - text change, update or insert. The estimate includes
> any admin on top > 4 hrs - Slightly harder tasks - change method, single new
> method - inc unit testing, and admin

Then it gets more complicated - I try to break down into the above problem
sizes, and attach a confidence level to the estimate of low, medium, high and
attach a contingcy of _1.25(high)-_ 2(low)

I try not to spend too long on the estimates, unless its a later iteration as
the initial round often requires redesign

------
dlahoda
.. tools. Tools embed knowledge and frame its usage.

Plan via [1] and consense via [2].

[1]
[https://alternativeto.net/software/projectlibre/?license=ope...](https://alternativeto.net/software/projectlibre/?license=opensource)

[2]
[https://alternativeto.net/software/firepoker/](https://alternativeto.net/software/firepoker/)

------
davewasthere
It's been a long time since I read it, but this was a good intro for me back
in the bad old days...

[https://books.google.com.au/books/about/Software_Estimation....](https://books.google.com.au/books/about/Software_Estimation.html)

EDIT: And don't forget the Atwood estimation method. "It'll take between 6-8
weeks". 60% of the time it works every time.

------
jrs235
What are we estimating?

Lead times (calendar time until in production) from time asked for estimate?

Lead times from the time the work begins (since sometimes the time the
estimate is made and the time when the development starts can have gaps,
sometimes small, sometimes large)?

Developer/development effort (in "man hours")?

Each estimate is important and has it's own use(s).

What estimates do people tend to provide here?

------
theraccoonbear
I have a coworker whose somewhat cheeky method I often cite. Think about the
task, guess how long it'll take you, double it, shift units. I usually get a
wry look from our project managers when I mention it.

e.g. 1 hr = 2 days, 2 days = 4 weeks, 4 weeks = 8 months, 8 months = 16 years

------
sidcool
Points are a good way to estimate complexity, but it does not help communicate
with the business stakeholders. They don't understand points. There must be a
way to convert points into days. Direct estimations in days almost always miss
by a lot.

------
PaulHoule
[https://www.amazon.com/Software-Estimation-Demystifying-
Blac...](https://www.amazon.com/Software-Estimation-Demystifying-Black-
Art/dp/8178531038)

------
mdekkers
My methodology for estimating a development project:

1: Ask the team for estimates on each dev task 2: Double the estimated time
for each task 3: Add an additional 25% contingency overall

This usually comes more or less on time.

------
mrweasel
As others have suggested: Start by breaking down the task into the smallest
part possible.

The absolute best way of estimating development task we've seen was suggested
by PHK (of FreeBSD fame), or at least I remember it as one of his suggestions.
Basically you take your absolute best guess on a task, multiple that by two,
and move up one unit of time.

Example: My guess for task X is 2 hours.

2 hours times 2 is 4 hours

Move up a unit, that's 4 days.

My guess for two hours can realistically be completed in 4 days.

This prevents you from taking on to large tasks, guessing that you could bang
out a project in 5 weeks would realistically be a 10 month project. A two year
project will be done in 40 years (4 decades).

It not a realistic way of estimating time of cause, but it illustrates the
dangers of tackling to large tasks.

~~~
supratims
We work in smaller teams in a scrum like environment. Our tasks are small
ranging from 2-7 days mostly. To make it easier for us developers to
communicate estimations higher up, we do following :

* Split work as small as possible, and atomic so that aborting/undoing is possible if required. Like all teams we do throw away a lot of stuff. * If a task contains 5 bullets (best case), we would only give an estimate for the bullets that we know for sure can be done without further dependencies and complications. We refrain from providing an overall estimate in such cases. * We often proceed with starting a task, and as the task progresses and more clarity emerges, we revise the estimate. Importantly we are encouraged to raise flags as early as possible. * We have dev servers that we spin out frequently to stage things that are in progress to test. They may break but give us early feedback which is crucial. Sometimes helps to stop a task earlier rather than later.

Still not a perfect system, but works for us without causing too much
friction.

------
CiaranMcNulty
By far the best method is actual information about how long similar tasks have
taken you before - even at the project level

We are much better at looking backwards than we are at projecting forwards

------
cbushko
Personally, I break everything down into 1 day sized chunks. It helps scope
out the problem, creates a to-do and check list of what it takes to get the
entire task done.

------
kovacs_x
Why You want it as a list? You're doing some sort of research or just out of
personal interest?

My $0.02 on this is the more You understand the problem You're solving and
details, and more are using the tools and technologies You have experience
with, the more correct Your estimates will be. No book or methodology will
help You with that!

The more unknowns, the more Your estimate will be off eventually.

It's simple really! :D

------
chrisweekly
Tangential quote (sorry, no citation handy)

"Plans are worthless -- but planning is invaluable."

------
dserodio
"Agile Estimating and Planning" by Mike Cohn is pretty good.

------
robschia
Take the most pessimistic estimation and multiply it by 2.

~~~
virgilp
This guy's estimation is pessimistic.

Multiply it by 2.

------
nol13
3.5 days

adjust task size accordingly

~~~
PaulHoule
See around 0:47 in this video

[https://www.youtube.com/watch?v=qtj7gVRjdZI](https://www.youtube.com/watch?v=qtj7gVRjdZI)

This is a running gag in the series.

------
cottsak
I've spent the last few weeks condensing years of experience and many
successful agile teams process into a concise and holistic guide which can be
found here: [https://agileforleads.com/](https://agileforleads.com/)

Here is my verbatim section entitled "8.3 Estimating a Story". Be sure to take
take this in the context of the whole process and tooling, which is covered in
detail in the ebook [https://agileforleads.com/](https://agileforleads.com/)

>

Remember how I said that if you only take one action from this course to your
team it should be the Retro? Well, the second most critical action to your
#agileforleads process is the Estimation; specifically consistent and
repeatable estimation. Sometimes this is called Backlog Grooming or Backlog
Refinement. Those terms don't work for me because they suggest that it's kinda
optional, and for us, it isn't. Other teams call it "pointing [a story]" and
you'll see why below.

Not every Agile process will be scientific. Many of the common agile patterns
don't need to be. Scrum practitioners will generally apply the following but,
as usual, I'm going to refine it a little more for you so that it's not only
easier to use, but substantially more valuable.

Don't get stressed or hung up on being careful to ensure that you pull off
estimation activities "by the book" because I've said it's so important. Just
carry these tips with you and try to throw a new one in each time and
eventually, over time, you'll find a consistent groove.

Being able to reliably predict future delivery rates based on historic
delivery rates requires control. Controlling the inputs ensures more accuracy
for the outputs. It's just science.

The rules for our estimation are the following:

* We use "points" instead of hours or person-days. Our points are a Fibonacci sub-set: 1, 2, 3, 5, 8 and "too big".

* We use Planning Poker for "throwing down a number" and we use our hands to do it. Avoid apps and playing cards if possible. Like the Retro voting, we don't reveal votes until everyone has silently selected a number. Everyone reveals together.

* When there is only a single size difference (eg. min is 3 and max is 5) we "go large" (select the 5).

* Use all 10 fingers to indicate "too big" and as early as possible, break these down into 2 or more smaller stories.

* When there is wider deviation, a "low ball" team member gives reasons for their low vote and the "high ball" member explains theirs too. Then discuss.

* Limit discussions (strictly 2 mins if you have a lot of stories to estimate; use a stopwatch) and invite a second vote to zoom in on a number. Two, maybe three, rounds of voting should be enough to get to the same number or a single size difference. If not, split the story or create a Chore to investigate the requirements further.

* Log blocking questions for the PO, update the AC/this is done when as you better understand the story, and add notes/reference links to the description while you're discussing the work.

* Log the agreed estimate/points number at the end and quickly move on to the next story.

Have a look at the following scenario and then after, I'll unpack some of the
details.

How-to: Simple Story Estimation using your hands

Team estimation need not be a formal ritual. Two developers at a desk is
enough. On other occasions where you want to move quickly through many stories
(you've just cut up a large block of work and the PO wants a date), booking a
meeting room with a bigger selection of your team gives everyone focus, and
increases the accuracy of estimation.

1\. Gather team members together.

2\. Open up Tracker and expand the story detail (so the title, AC and any
attachments/images are clearly visible) so everyone can see it.

3\. Invite someone to read aloud the story and it's AC. Show larger views of
attachments. Someone could summarise or add a little more detail verbally if
that helps.

4\. Ask members whether the story is clear enough on it's own for everyone to
"pick a number" (silently). If not, ask and answer questions for a couple of
mins and log questions down for the PO that the team can't resolve on their
own.

5\. When members "have a number", ask everyone to hold up closed fists and
count backwards from 3 to reveal votes simultaneously. "3\. 2. 1. go!" Single
finger for 1 , 2 fingers for 2 , etc, 8 fingers for 8 and all fingers for too
big .

6\. Jen votes 5, Alex 2, Kate 3 and James 2. Since she's high, the facilitator
asks Jen "why the 5?"

7\. Jen, who got caught up seeing the css and js note explained a concern
which the other team members quickly identified as confusion. Once the issue
was clarified Jen exclaims "Oh! Sorry, I'm a 2 then as well".

8\. Another member asks "So go large then?"

9\. And the rest of the team agree. The facilitator logs 3 as the estimate and
open up the next story.

I know this example doesn't cover all the scenarios and variables but I'll try
to cover many questions I hear frequently and some of the more common
variations.

* Let's start with story points. Developers are notorious at estimating very inaccurately when it comes to hours and days. Just ask any project manager. It's also a recipe for bias too - I want to show my team and myself that I have a handle on something and I can do it (quickly), so I'm mentally incentivised to offer a smaller than reasonable number. Most developers often estimate by a factor of 0.5 or smaller when using linear time. Points push all that to one side and free a technical team member to think more clearly. We usually say that points are in terms of "relative complexity or effort". Complexity works for some personality types. Effort for others. The other thing to note is that a 2 is not necessarily twice as much as a 1. Think of 1, 2, 3, 5 and 8 simply as containers. 5 is the "middle of the road" container and 1 is the smallest thing the team will ever do. In that "1 container" might go a one line change that takes 10 mins or a re-styling effort of 3 hours. But it's the smallest so the smallest items of relatively the same size get a 1. 8 on the other hand is absolutely the biggest thing any member of the team wants to commit to in an iteration. If your iterations are 1 week and Bob thinks the story can be done in a week but Sarah thinks longer, then it's more than an 8, and should be broken down.

* Less tools is more. Avoid the Planning Poker cards and apps and just stick to your hands. This also influenced the selection of Fibonacci numbers. We don't use the size 0 because it's somewhat confusing and dangerous (like a Chore - more later). We don't use more numbers because you get diminishing returns by increasing the resolution of estimates too much further. Tracker also offers "t shirt sizes" S, M and L which I've found helpful for planning heaps of work up front very quickly but not particularly practical for day to day work or new teams to this process.

* At all times, remember: we're just estimating. I'm preaching to myself here. I often have to remind myself that these are all just estimates. It helps you relax a little and not apply as much pressure to yourself (and your team mates) and sometimes get to a number quicker.

* Use the Done column to reset your base of reference. I didn't include this in the narrative above because if you're estimating regularly (every 2-3 days), each team member subconsciously knows the relative scale of each point container. But on more occasions than not, it's helpful to pull up the Done column in Tracker and refresh the team on what each size means, using recently completed work: Scroll to the bottom of the Done column (most recent completed iteration) and work back until you find 1 or two of the various sizes that the team is debating match the container for the current story being estimated. This is another mechanism to ensure consistency over time for the estimation inputs. You're essentially reminding each team member "what a 3 looks like" or "what a 5 looks like" prior to each silently forming their estimate. This historic reference is vital in ensuring that work of the same relative size receives the same estimate over and over again.

* PO does not vote. After a story is defined, the developers usually estimate it. Sometimes other members of the build team can help but this activity must absolutely exclude the PO. The PO has a conflict of interest when it comes to estimating how big a story is, so they need to stay out. If your PO can sit in on the discussion to answer questions and further clarify, then that can be helpful but I've found they often influence the estimate, sometimes simply by being present. If you can find a way to meet with the PO and clarify the AC separately and estimate without the PO, I think you will have more success. Discuss in your Retro if you have issues.

This, like many practices, simply gets better over time. It's ok for it to be
little slow at first. Like commits, stories, iterations and release phases,
the smaller you can batch things, the faster you'll cycle and quicker you and
your team will learn.

