Ask HN: Best practice for estimating development tasks? | Hacker News Reader

Ask HN: Best practice for estimating development tasks?

74 pointspacifika71 comments

Would like to see a list of resources that would be useful to help improve estimating skills.. books, resources, methodology etc.

View on HN

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.

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...

1: https://en.m.wikipedia.org/wiki/Cynefin_framework

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

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.

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...

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?

Yes, to both your rant and question. Shoot me an email at the email from https://github.com/andreis, we're hiring remotely and in several countries. Either React or Go experience or interest is appreciated, since we're using both extensively.

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.

Sounds like you might be making other people look bad by coming under.

"The nail that sticks up gets hammered down." - The Underachiever's Manifesto: The Guide to Accomplishing Little and Feeling Great[0]

Complete bullshit and a horrible culture to be if you truly care about progress and doing your best.

[0] http://amzn.to/2EwCNOx - affiliate link

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.

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/...

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.

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

Multiply by 5.

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

And finish the sentence with "...probably"

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

How about, "if all goes well" instead?

Much better :)

In my experience, the bigger the project, the bigger the multiplication factor. On a big enough scale, multiplication by 2 might be not enough. Most often I find that implementation times can be estimated quite reasonably, but time for testing, documentation, team-coordination and communication are not factored in properly.

Then increase the unit of Time by one.

2 hours = 4 days

3 days = 6 weeks

2 weeks = 4 months

If you have already done it multiply by the Golden Ratio Φ. If it's a new task multiply by Pi π.

It is true that we suck at estimating. Doubling helps you get closer since you always think you'll be less busy and have less distractions. You can also get really good estimates by breaking all tasks down into things that are less than one day. However, this takes time as you are really doing investigation that is part of the task itself to figure out how many sub-day tasks you need for a bigger task.

In the end, estimating is bad for how people use it (imo). It is used to make gantt charts and plan release dates which are useless. It is much better as a personal tool to track how effective you are at turning concepts into working products. If you track time, it should be so you can reflect and improve.

We all really need to move to prioritized iterative development (not scrum) where the team is working on the highest value items in prioritized order. This also means cross training so people don't say things like "Jill doesn't know the image processing code so pick so other (lower priority) task". If you are always completing the most valuable tasks, everything else will come out in the wash.

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.

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.

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."

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"

>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.

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.

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.

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.

my rule of thumb was if it takes 4 hours to develop, I'll always said 3 days, as then You account for some unknown, testing, building / deploying, maybe some refactor after review, etc esoecially as it was for a product that will run for 10-20 years, with changes allowed like once per year. In 60-70% I'd finish in 1-2 days, but in those 30% it's always good to have extra day available for additional development or debugging or anything else or You can always tell You're finished ahead of scedule and feel really good about Yourself! :D

There's a book Software Estimation Demystified by Steve Mcconnell

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.

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.

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.

>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.

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 :)

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

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

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/

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.

(shameless plug) I'm the creator of: 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.

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

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...

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.

My boss wrote up our way of communicating those 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.

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.

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

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".

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

Not enough.

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

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

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

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

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

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....

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

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?

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

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.

https://www.amazon.com/Software-Estimation-Demystifying-Blac...

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.

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.

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.

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

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.

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

Tangential quote (sorry, no citation handy)

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

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

Take the most pessimistic estimation and multiply it by 2.

This guy's estimation is pessimistic.

Multiply it by 2.

3.5 days

adjust task size accordingly

See around 0:47 in this video

https://www.youtube.com/watch?v=qtj7gVRjdZI

This is a running gag in the series.

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/

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/

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.

Reply on news.ycombinator.com