Best techniques for Estimations?
Posted by GraphicalBamboola@reddit | ExperiencedDevs | View on Reddit | 48 comments
What are the estimation techniques which have worked for your teams especially in terms of meeting the deadlines for project delivery? e.g
- High level estimations of a project to come up with an expected delivery date
- Estimation of individual tickets
Can you guys share how you deal with the above to cases which have worked well in your team or companies?
I'm heading a team where we will need to come up with an estimation process so I'm up for all ideas
bigorangemachine@reddit
I always say that if you want more accurate estimates give me more time to do them.
GraphicalBamboola@reddit (OP)
Keep notes?
bigorangemachine@reddit
Ya everytime you dive under the hood i would keep notes.
Just bullet points.
Like if you taking apart an sql view just note what tables are joined in the view...
runitzerotimes@reddit
What?
bigorangemachine@reddit
I have a NOTES.md on my desktop.
We use a of SQL views so having to dig into what each view is doing takes a long time because its views-of-views.
So I just keep notes so I don't dig through old migration files again and again
The more time I have to research code for estimations the more accurate they are. So if I can optimize the code that doesn't change for notes... I save a lot of time just reviewing notes
runitzerotimes@reddit
I too have notes
Sticky notes for the win
(Please get me out of my tightly controlled windows corporate environment)
attrox_@reddit
I tried many different estimations and they never work. What's work for me is to go with the first gut feeling I have. Once I have that number in mind, I double it.
tuna_74@reddit
How did you measure/follow up?
tuna_74@reddit
For individual tickets: Follow up actual result in time spent. This require that you log the work time on each ticket which adds overhead. But after each sprint (or month or whatever) you can follow up the result in aggregate and see how close you where. If you estimated 10 tickets to 200 hours in total and you actually spent 214 hours you are pretty good!
Estimating is pretty pointless unless you actually track the result.
SpriteyRedux@reddit
hfntsh@reddit
The only truth is that the closer you get to doing the work the better estimate you have. So obviously we don’t want to complete the project before giving an estimate, but if we can break it down to very small tasks, point out risks and perform PoCs we can get a better estimate.
The further away from the work we are the more unknowns we have and you need to budget and buffer them.
Also don’t ignore reality and don’t believe the lies. A common pattern is “in the past projects of type X used to take two months, but we improved stuff so it should only take a week”. We don’t adjust estimates based on hope, but based on experience. When I’ll see such a project end in a week I’ll be willing to take that into account.
MoreRespectForQA@reddit
Not estimating actually worked best in terms of meeting deadlines.
This sounds infeasible but it worked for quite a while - nobody really worried about our estimations if our team an objectively quick turnaround and delivery was almost always waiting on some other team.
At some point, we were forced to implement a process for estimation along with a bunch of other stuff and it was like a frying pan to the head in terms of objective delivery speed.
Altruistic_Brief_479@reddit
You just described in great detail why I never advocate for true scrum. Just hack something together before this arbitrary deadline or it will kill our sprint completion percentage! I'm not sure I ever met a stakeholder that cared more about predictability than velocity at the end of the day, but somehow we need to optimize for predictability instead.
ClydePossumfoot@reddit
I’m convinced that we should just have JIRA pick a random number on the fibonacci scale between 1 and 8 for each ticket and then just see how we fare.
We’re going to either come in above or below it each time for so many varying reasons so it doesn’t really matter.
loosed-moose@reddit
Just double it
t3klead@reddit
Take your best guess. Multiply by 3
rayfrankenstein@reddit
I’ve heard people have good success multiplying by pi.
HolyPommeDeTerre@reddit
Top comment says that they don't care for estimates. I think it's true but we can deal with that. And protect us at the same time.
What we do currently:
High level: T-shirt sizing, we define a scale XS to XL. We define broad timings on that. We split the epic work into different solutions and iterations. We size each part. Sum it to get a very broad estimate of it. Add up 30% (at least).
This will give you what the team thinks it'll take. At this point we need to check that the budget allocated to the epic is matched. We negotiate on what is important or not to get into the budget. That's the part the top comment is talking about: they don't care about the estimate because they have a budget we need to match. Once you find the right balance, you start refining and defining low level estimates.
Low level: story point, the scale isn't based on time but complexity. At this level we should have enough information on the task to put a complexity score on it. This doesn't relate to time. At this step, you know the dependencies and how hard it is to achieve the task. Priorization is easier.
This technique is currently working. We insist on the fact that we don't give a date. We try to stay in the budget, that's all. Giving a date is shooting yourself in the foot. Context of development will change and the date can be bypassed. We can give a date when we are already 70/80% of the work done.
rcls0053@reddit
#noestimates. It's the extreme opposite of estimations. I agree with the notion that estimates are never correct. Unless you've done the exact same thing a hundred times, and that's very unlikely. So you just guess.
If you have to guess, always multiply it by 1,75 at least. Never estimate anything big. You think a project takes a year? It'll take at least three.
What I would say is read "The Art of Slicing Work". It goes through the whole process of thinking work as a vertical slice, and gives you real world examples of how you can think about the process to split the work into small chunks that you can estimate take, let's say, one day to complete.
No idea who thought estimating through some magical Fibonacci number makes sense. This whole game we play is just idiotic.
Admirable-Guide6145@reddit
You don't estimate time based on the work, you estimate work based on the time, this way you never go past the deadline, you go over or under on the work done.
dbxp@reddit
PERT estimates: https://en.wikipedia.org/wiki/Three-point_estimation
They're surprisingly accurate and way quicker to do as you just need to give vague figures rather than thinking in detail
UntestedMethod@reddit
Yep. I have used this when working as a contractor. It really helps avoid under-bidding.
This is another excellent point. Having that detailed implementation plan up front is key. Every developer should practice task break-downs as a core skill.
Also identifying uncertainties as early as possible, resolving as many as possible upfront and allocating time to resolve the others before they impact the project. Similarly identifying external dependencies as early as possible and planning the timelines and communications/prompting for them as variables in the overall plan - as a contractor this was often input from the client's business end such as providing specific assets, making specific decisions, acceptance testing, etc.
But now this is starting to sound a lot like waterfall, but ultimately you can't estimate what you haven't defined and there are always task inter-dependencies and variables in timelines. Idk but most teams probably aren't doing tiny projects that fit into 2 week sprints then change direction anyway so why skip the upfront planning.
UntestedMethod@reddit
Yep. I have used this when I work as a contractor. It really helps avoid under-bidding.
This is another excellent point. Something I've learned to do is to identify uncertainties as early as possible and allocate the time to resolve them before they impact the project. Similarly identify the external dependencies as early as possible and plan the timelines with them as one of the variables - as a contractor this was often input from the client's business end such as providing specific assets, making specific decisions, acceptance testing, etc.
Dexterus@reddit
Can get time consuming to get confidence. But works great. Just remember to add a 10-25% on top, based on how familiar the devs are with the work.
dbxp@reddit
I find itich quicker personally as I don't need to think so much
GraphicalBamboola@reddit (OP)
Interesting! I think that's what Uncle Bob suggested as well in one of the videos.
Not sure what you mean by you need to have all the stories? So are you expecting to have discussed all technical details and broken down work to each ticket before coming up with a deadline?
Sometimes managers are asked to give a high level estimate which wouldn't require involving all the devs, how would you deal with it?
dbxp@reddit
We usually have the titles of the stories but not the contents when doing high level estimates. I'm just mentioning it as in the past we've been missing entire user flows which obviously meant the estimates were useless.
I would break out the epic into story headers and then give them a brief point, then add 20% contingency to the total figure. Just be very clear that these are high level estimates and not something which deadlines can be based around.
GraphicalBamboola@reddit (OP)
and then I guess once the high level estimates are in then you go through proper planning involing the devs to fill out tickets and estimating each one and then you will have the exact deadline you will be working towards?
ClydePossumfoot@reddit
The process you’re describing barely works when building a bridge, much less building software with way more unknowns.
GraphicalBamboola@reddit (OP)
So what do you suggest?
ClydePossumfoot@reddit
Oh I have no real suggestions because the task that is being asked doesn’t make any sense outside of like.. factory style software development where you’re just doing the same thing but slightly different over and over.
My best suggestion is to just make up numbers and tell the stakeholders that is what you are doing until they get the picture or fire you.
dbxp@reddit
We don't fix a deadline, we work semi agile which means priorities may move about
fig-lous-BEFT@reddit
I like the poker planning approach: devs come up with a bet by asking questions then the average of the hands is adjusted by some fudge factor.
YetMoreSpaceDust@reddit
I learned early on (although longer than I would have liked): they don't want estimates. They never want estimates. They've already decided how long it's going to take, they want you to telepathically figure that out and tell them. Believe it or not, this is a skill you can develop. Note that estimates are completely meaningless, nobody will ever check if you met them (if they did, everybody would be fired).
PoopsCodeAllTheTime@reddit
"Say the number I imagine or lower, if you say something higher then I will tell you it's too high."
This is the stupid game, same as salary negotiations.
Anchor higher than their number, slowly change it until it's ok I guess?
Literature-South@reddit
Whatever you do, don’t use binary search to try to find the number. You’ll fuck yourself.
vangelismm@reddit
No Estimates.
Sethaman@reddit
I like to roll a d20
wasteman_codes@reddit
I personally don't think any specific technique for estimation has been more accurate or contributed to better project delivery based on my experience. I think what mattered most was a team that spent time digging into the requirements at sufficient granularity before estimating, and then constant communication with stakeholders.
The point of estimation is that it is useful for different groups to plan together, and if you are constantly communicating the cost of being wrong decreases significantly. There are obvious edge cases like that wild CEO that commits an aggressive timeline to clients etc, but in general I find that if you have good relationships with stakeholders, constant communication becomes the biggest factor.
_ncko@reddit
Use data. Keep track of the tickets your team completes and how long they take. Then you can use data to determine that X% of tickets are completed within Y period of time. This gives you a confidence interval. So you can tell management "We are 90% confident that we will complete this project (which contains 100 tickets) in 4 weeks, and 80% confident we will complete this project in 3 weeks."
If you put your projects in a prioritized backlog then you can actually set dates with confidence intervals. And you can easily adjust if a project goes over or under.
A great talk about actually using data for estimates instead of just having people guess by Cat Swetel.
wlonkly@reddit
You get better at it with practice. One thing that devs are not good at is checking how good their estimates were. If you think a ticket is going to be 3 days, or an epic is going to be two weeks, or whatever, at the end, you need to see how long it was and compare it to your estimate, and see why it was different. Only then can you use that new information to improve your next estimate.
FarYam3061@reddit
its not as hard as people make it out to be. before you solve a problem you have to completely understand it. thats a whole other process, so lets assume you know the problem and have a clear path forward. write out the implementation steps, then break those down into smallest possible tasks, estimate based on intuition, if something feels like it's risky, write it out and talk to someone about it.
ClydePossumfoot@reddit
I’ve never been in a planning and estimation process where anyone “knows the problem”, “completely understands it”, and has a “clear path forward” for anything non-trivial.
Usually at that stage the Lumberghs are expecting folks to have those details but have dedicated zero time to allowing engineers to actually understand the problem before asking for a hard date on when it would be done.
freekayZekey@reddit
recommend “Software Estimation: Demystifying the Black Art” by McConnell. that helped me with estimations. now i don’t worry so much about getting them “right” as long as they are useful
you could ask what the deadline is and see what features you can realistically fit within that deadline and negotiate.
Howler052@reddit
Think of the time it might take to do the work. Double it.
Always under promise. Over deliver.
amk@reddit
I just heard about Quantified Tasks https://quantifiedtasks.org, where you assess tasks from 1-5 on three dimensions: Distance, Friction, and Relativity, and then combine the values. I'm planning on trying it, at least for my own estimating, and seeing whether it works for me.
DeterminedQuokka@reddit
Exponential for large projects. 2,4,8,16 weeks
Mostly time based for tickets. 2 hours, half a day, a day, 2-3 days, a week.
Don’t estimate with a specific person in mind, but acknowledge that the person does matter. A ticket can’t go from a 2-5 because Jake is working on it. But you can say “right now Jake does fewer points”
AceHighFlush@reddit
I've done them all.
I'm a big fan of simplified sizing for each ticket (by the devs).
Choose from: 1, too big, don't know.
Too big get split. Don't know gets a timeboxed spike. All of the 1's average out over time to give a predictable velocity. This makes estimations really fast so devs can get back to building instead of arguing over a 3 or a 5.
The hardest part is not estimating the current backlog. It's backlog growth management and scope creep. Also, only size planned work: walk ups, and short notice work is 0.
Remember you want to know how much backlog you're getting through, not how busy your team is, to predict delivery. So you should also be tracking backlog growth over time vs. completed.