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
Latest comments (20)
As a lead engineer or manager, you can improve task estimations by breaking tasks into smaller components, leveraging historical data, and encouraging team collaboration. The Madeira Thread Used approach emphasizes weaving past experiences and insights into current estimations ensuring more accurate and realistic timelines while fostering continuous learning and adaptability within the team.
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
"what done looks like?" is the question I was looking for. Thank you so much!!
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.
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 :)
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.
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 :)
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
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.
Roll a dice and add it to the estimate 🤣