One of the scariest things to reply back to another human being as a Software Developer is the dreaded question:
"How long is it going to take?"
We all hope we could answer "Whatever it takes" to our managers or bosses, but we need a stable income in our lives.
Some people come up with arbitrary times, whether it's a few days, a week or two, maybe 3... but we can all agree that overshooting and getting it done sooner than expected makes us look way better than undershooting and responding with the classic:
It was more complicated than what I expected...
Some people prefer using points systems, others might argue that time intervals might be better... But ultimately, we can all agree that we all, as human, are pretty terrible at estimating.
So, how do you do it?
Top comments (18)
I wrote an article about this subject and linked to your article from it @chrisvasqm, just letting you know.
I was usibg the idea of presuming hiw much time a task needs then addibg 45% to it. But it still didn't do a good job of creating a reasonable estimate.
What @sarthak and @leonid medovy said, are usefull information which i ll try to introduce in the estimation process.
The float and slack idea sounds good.
One of best responses i read. Also quite informative. Thank you for the float Nf slack concepts.
This is a problem many need to face.
Thank you
Multiply everything by 10. That way you can always "underpromise and overdeliver".
That isn't possible in small companies or big ones where pm whats stuff done quickly. To maximize profit and look good in the eyes of the client...
I don't, but have to as I have been told by managers and supervisor. Really problematic if you are dealing with the wrong person. There are psychological factors involved that are not in your control but you have to deal with.
It's hard to tell it in advance, that's why they call them estimates. Also it's important to let other party know that you gave estimates not the absolutes.
If you hit the block just keep updating people in real-time so they can prepare themselves in advanced because if you be hard on yourself and try to spent a week trying to reach some estimate and then fail to do it because it was impossible. Then when doing weekly meeting. You talk about your issue while they were expecting great, unrealistic things and you tell them its not done. They would feel you have taken something from them. Yup, it was fantasy idea, some expectation that job would be done (
not that its not done it would take ___ time more, omg delay- their thoughts) but things aren't as simple are they? so that's something to be aware of.Just simply, "Don't promise you will give someone $200 and then don't give" because even before they get $$$ they believe they already have it, and then on the day when you have to and can't they feel you have taken $200 from them.
Yeah, that makes sense. I generally do two-three rounds of estimation. I start with "t-shirt sizing" -- small, medium, large, x-large, etc. These have some very loose definitions (small is up to 1 sprint, medium is 2-3 sprints, large is 3-5 sprints, etc). However, these should also have the number of resources/developers that need to be dedicated included as well.
Second round is after I've had a chance to dig into the code a bit, do some high-level technical solutioning. At that point I should have a couple of options -- a quick-and-dirty approach that includes a follow-up to clean up technical debt but gets the feature out the door ASAP, and a more stable, scalabe approach that may take longer to ship but will require less maintenance long-term. I deliver these to the stakeholder(s) and answer whatever questions they need to decide A or B.
Finally, there's the detailed technical solutioning where I chunk the larger feature into individual stories and tasks. Here I can start to add detailed estimates to each one with a goal of making each small enough to be A) discretely completed, and B) accurately estimated. This is when I can actually move these PBIs into a planned Sprint and call them "Ready to Start".
Edit: I think that saying Agile breaks down when you enter uncharted waters sound like the problem is more in not planning enough before the work starts. That's not an Agile-specific problem - that could just as easily happen in waterfall, kanban, or any other project management approach. In my experience, the business doesn't always want to allow time for planning (because it doesn't seem like productive work), but the business also always wants to have clearly defined timelines so that it can forecast and measure delivery. It's silly to try to fight that, so I have just adapted to use those business needs as the justification for that planning space.
I prefer not doing it, and if someone insists on getting an estimate I have to remind myself to add 100% on top for reviews, refinements, and pointless discussions. Rule of thumb: if you think you can develop it in 1 - 2 hours, the correct estimation is one day.
I get what you're saying, and I don't disagree, but I did want to contend with one point - story points, specifically.
First, story points are not an estimate of time. This hits close to home for me because I've been working with my own company to clarify this for close to a year. Story points are an estimate of the level of effort required to deliver a story. This should be in comparison to other work that the team has delivered in the past.
Many people try to equate it to time in the name of pRoDuCtIvItY; they look at the measured velocity of a team and then divide that by the number of days or man hours in an increment and start to formulate a ratio. This is an Agile anti-pattern -- pointing is relative and specific to the team's strengths, subject domain, and environment as impacted by their technical debt.
Also, we shouldn't be pointing complex tasks. The tasks should be refined until they are as simple and plain as can be. This helps ensure that as many of the "unknown unknowns" have been addressed as is possible. In my experience, we are not great at estimating, but we can look at a task and say, "that's awfully similar to these other 2-3 tasks I've done before." Then we can say those 3 tasks averaged 8 points, so it's likely this, too, is an 8.
I prefer time to points, using half-day to day intervals, and overshooting when possible. If it looks like it takes longer than one week, I ask if it can be split into multiple tickets, even if both of those still are assigned in the same sprint.
Firstly we refine tasks until they are simple or further division would just turn it into a wonky list of steps.
Second we estimate minimum and maximum, or optimistic and pessimistic variants. We give those min/max as our estimates. Sometimes they vary a lot if a ton of things can go wrong and even simple tasks get something like 3-24h estimates. But that way I am pretty much always between those, and over time I learn how to estimate it better.
Another thing: if estimates are extremely hard and don't get easier over time it may mean that code quality or quality of processes is lacking and you should do something about it.
For example maybe builds just fail sometimes, or compilation takes hours, or maybe automated tests are nondeterministic, or maybe whole code flow pipeline is overcomplicated because to deploy you need to email someone from other side of globe to manually copy files to server. Maybe your code is so complex that even simple things are hard to do and can fail in lot of places.
Either way, failed estimates and slow work definitely are a sign something with code or process is wrong.