As a lead engineer/manager, what steps can you take for your team to provide better estimations for their JIRA stories or tasks before starting the development work?
Dollar Dhingra
Posted on
As a lead engineer/manager, what steps can you take for your team to provide better estimations for their tasks?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (19)
I think the best thing you can do is getting them to understand their own bias (either way, too high or too low) and compensating for it.
Another thing you can do is having broader values instead of trying to be super specific (can you really tell the difference between something that takes 3 weeks and one that takes 4 weeks?).
At a previous job we also did estimates in groups and had discussions when people wildly disagreed on them.
At Aha! (disclaimer I work at Aha!), my team uses half-days, 1 day, days, weeks, and months. Anything bigger than a week usually gets broken down before we start working on it. Other teams prefer points, some use the Fibonacci sequence (1, 2, 3, 5, 8, etc.) or whatever works for them.
Thanks for the detailed information, that's really helpful
I find it most helpful to have as much context, clarity, and focus as possible. Clear business problem, clear direction, clear scope, and clear steps. The more prework or context that can be brought to bear, the more useful the grooming and estimations.
Basically, a good JIRA ticket is FAR easier to estimate, and that's the true art.
True that, I strongly agree on the point that a good JIRA ticket is far easier to estimate
Depend on the project.
On heavy legacy software, estimation are really hard because when you touch something, everything may collapse. So there are a LOT of unknown. For this kind of project, I use to create a "ponderation sheet". For ex., when touching this module, when implementing this kind of feature, or when facing this kind of complexity (multi-thread, multi platform, etc...) we know we should ponderate the initial estimation by *1.5, *2, *3, or add an uncompressible time like +2 days. It is completely arbitrary and based only on experience, but it works.
On younger project, you can use estimation in T Shirt size, points or whatever. This generally translates by "does it take 1 day, 1 week or 1 sprint ?". If it is more than 1 sprint, split the story until doable in 1 week.
And as a rule of thumb, "You cannot put 12L in a bucket of 10L". So if it takes 2 days, it takes a week.
I also wrote an article concerning large project estimation. Hope this can help : kissyagni.wordpress.com/2022/04/11...
Thanks for article :)
The only way to get accurate estimates in my experience is to break every project down into its simplest component to where each task/story should take no longer than a day to complete. And when I say 1 day, it's something you tell yourself that you could have done in an hour.
It's tedious and time consuming, but it's the only method I've found that's even remotely accurate.
Define better what and how you are actually estimating. It makes a difference, if you estimate time or complexity as well as if you are estimating with people in mind (different skills and experience!) or trying to estimate with some kind of average. Finally, estimations are just estimations, do not expect too much.
That's right, most of the time we do not estimate with people's skills and experience in mind..
It takes some time but estimation poker should help in this case. Each member of the team does the estimation, lower and higher describes what they thought. After that the team give the final estimation.
Software estimating is impossible. In my 30 years, it never worked until Agile changed the concept of Software delivery.
Agile correctly says Software is never done. Rather, it says we will collect all new requests and order by most value to product owners.
From there it uses Fibonaci numbers to determine difficulty. Anything 8 or above is split into two tickets.
Continual backlog grooming allows for new priorities to be established.
No time commitments are needed because delivery is continuous. Each delivery only contains the most valuable items for a given period. Usually sprints are 2 weeks.
Automated Tests are required for each checkin.
Each checkin requires one or more quality gates. Code reviews ensure the implementation meets the architure, but bans bad coding practices. This ensures, over time, that the code base consists of bullet proof parts to be reused.
Following the suggestions above takes a lot of work and in many cases a retraining of those who love to set dates.
Just say no and never commit to a date, use continuous delivery and include the date setters in the planning meeting.
couldn't agree more
I'd implement 3 point estimation. Read Steve McConnell's "Software Estimation". It contains a great quiz I give staff to introduce them to the principles of 3 point estimation and aside, is the seminal work in the field IMHO.
The only way to get better estimates before your your team has started is by having people on the team who've already done work similar to the work you're estimating. The more similar the work they've already done, the more accurate the estimate. This is troubling, because typically doing work that's already been done before isn't valuable.
If you want better estimates it's good to understand what they truly are.
estimate = actual work to deliver - currently understood work yet to be done
As someone progresses on a piece of work, their understanding of the work remaining becomes better, and the amount of work done increases. The perfect estimate is known at the point in time the work is done. Estimates aren't a single number. They're a range which narrows and increases in certainty over time. Any better estimation always amounts - in some way - to doing the work.
I'm going to make an assumption here on what it is you're really asking for, apologies if this is wrong. I think you're really asking "how can I help my team ship work on better understood timelines?" Maybe you could even throw in a "negotiated against business constraints & outcomes?"
Grabbing a single data point up front and never re-evaluating it is a great way to end up with big gaps between the estimate and what actually happens.
The best way (so far) to improve estimation is something we do with aha.io/develop/overview . You have your feature ("what" is to be accomplished). This gets an informed value assigned via a scorecard, vetted & assigned up front by a lead. Work gets carved out into requirements on the feature. For bigger features that might have more questions or work in them, they get a requirement to learn more and build better informed requirements. As understanding advances, the scorecard gets updated. This makes it really easy to both demonstrate & track progress, as well as great for PM's to standardize/compare features apples-to-apples across the project.
Also, full disclosure, I work at Aha!. But many engineers can work a lot of places. So you should actually take this as the vote of confidence it is.
I'm sure, with some finagling, you could replicate the same practice I've described in JIRA. The point is, this constant carving of out of new requirements in the context of a feature drives a lot of conversations. Consistent conversations drive consistent timelines.
When you're carving out requirements, you discuss what the parts are, how they're connected, and the order to do them in. This typically unearths the unknowns. And the unknowns are the single most critical thing to eliminate to increase the accuracy of your estimating.
If what I'm suggesting above isn't feasible where you're at (I've been there - I feel your pain), hiding a little bit of dev work up front in your process (calling them "spikes," "shaping," "research" etc) is the next best way to increase the accuracy of your estimates. I once worked at a place where estimates weren't conversations but commitments carved into stone. A little bit of shaping out features & requirements before our big planning sessions made them so much better. I wish you good luck!
Thank you so much for your helpful comment. You are right, this is my question ->"how can I help my team ship work on better-understood timelines?". Also, your last paragraph is a ray of hope :)
Retros (retrospectives).
Also, I find estimates are often off due to the working environment, e.g. heavily beurocratic places are far more difficult to get tasks done. What might be 1-3 story points in a startup could be 5+ in a complex environment.
That only comes with experience I think.
Thanks for these points :)