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.
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 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.
"Why Asking Developers for Time Estimates in Software Projects Is a Terrible Idea and How to Bypass It With Scrum":
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?
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.
"The nail that sticks up gets hammered down." - The Underachiever's Manifesto: The Guide to Accomplishing Little and Feeling Great
Complete bullshit and a horrible culture to be if you truly care about progress and doing your best.
 http://amzn.to/2EwCNOx - affiliate link
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.
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/...
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.
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.
2 hours = 4 days
3 days = 6 weeks
2 weeks = 4 months
I try to avoid working with people/teams where I'm forced to make this kind of estimate. It's a great selector.
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.
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."
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.
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.
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.
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 :)
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:
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.
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.
* 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.
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.
> 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
Plan via  and consense via .
EDIT: And don't forget the Atwood estimation method. "It'll take between 6-8 weeks". 60% of the time it works every time.
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?
e.g. 1 hr = 2 days, 2 days = 4 weeks, 4 weeks = 8 months, 8 months = 16 years
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.
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.
* 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.
We are much better at looking backwards than we are at projecting forwards
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
"Plans are worthless -- but planning is invaluable."
Multiply it by 2.
adjust task size accordingly
This is a running gag in the series.
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.