It's hard to calculate the time you will need to finish the task, but it is equally important. Let's dive deep and understand how to do it?
Time e...
For further actions, you may consider blocking this person and/or reporting abuse
Almost 27 years of experience has taught me that estimation is a waste of time and a totally futile activity. Better to use that time simply getting on with the task
30 years for me. Only continuous delivery works in a 2 week sprint. Most valuable items only. No time estimates should ever be promised. Stick to Fibonaci estimates only.
I just don't do them at all
what if client & Scrum master insist on asking time estimation fo reach task ? is NO or Can't a good answer ?
For Scrum masters, I've told plenty that I won't estimate. If they insist, I tell them to fill in a number themselves. It does make for some 'challenging' conversations, but I think it's worth it.
The happiest, most productive teams I've worked on have been ones that are free to self organise - working in cycles that last 6 weeks.
For clients, good communication and managing expectations is key. Generally just showing them progress from time to time is the best way. Making dated promises is usually a sure-fire recipe for disappointed clients.
thanks for sharing your experience, appreciate it.
Yessir
RIGHT ON!!!
For projects and bigger tasks I am almost always spot on about the time I estimate. However I always multiple it by 2 since I know I will have some high priority issues in between, a sidetrack which needs to be done, internal solving some stuff etc..
It's not really the task itself. The problem is more (for me at least) how much do we get interrupted, and are the deep-code-sessions long enough to make steps fast enough.
Effort appreciated but this is very similar to SDLC which Agile replaced many years ago, all for good reason. Never give a time estimate rather provide a Fibonaci number. Convert to 2 week sprints and only focus on most value items for each sprint. That way impediments can only impact a two week period. Everything's tracked on a board.
I never estimate. Where I work now we just agree if a task is S, M, or L, meaning shirt sizes.
S = easy task, no need for any digging or help from other teams/third parties.
M = A bit bigger than S. Might need some outside help or at least some digging.
L = Will take a while and most likely needs a lot of outside help.
And since I have like a billion meetings everyday even a S can take me a week to complete in actual time.
Pretty well-planned approach you have there. I think it could work quite good. In my opinion it's quite time consuming though. You have to remember that time estimations normally involves many people, so an hour estimation meeting can be many more hours effectively.
I would suggest using agile metrics. In that way you can plan in points and the points will automatically correspond to a certain amount of time based on the actual time it takes to develop. The process is described here.
This is really helpful!
Great article. I use apps like Centered for tracking my time and productivity it has made a big difference for me.
Well in my team we have done an estimation agreement so we all kinda estimate the same way. We work on two week sprints, divided by goals each goal shredded in little tasks.
The tasks we estimate not by time but by storypoints and they have no relation with the task time but the task complexity, possible dependencies and how critical it could be. An the estimations are done using Fibonacci.
So, things like, creating a new module could be a 13SP something like adding a service 5SP, an changing a lokalise string or adding a tracking for Firebase could be a 1SP.
This take no time at all to do. We add the estimations during refinement. And after a task is done if we think it was wrongly estimated we have a special field with that only to see if this is getting common and we have to revisit the agreement or if it was a thing of one time only.
The system also help us to create like a team average so we can plan better sprints
Nice article! breaking tasks down in max 30 minutes is my favorite :)
That can easily lead you to micromanagement, loosing valuable time in bureaucracy and assigning the tasks beforehand so no teammates are self-assigning tasks from "your" feature.
Estimates only ever tells you one thing: How well you did in estimating the task.
Project management tends to not like this truth...
True; but also they can become self fulfilling prophecies when not unrealistic.
Yeah, true... why do it faster if there is no need...? Makes it counter-productive in the end. So, decide: is it a good tool? ;-)
One practical aspects of prediction is individuals predicting what they can complete in one workday. Walking away from partial work that’s at a good stopping point is always better than walking away from a mess you’ll have to look at again the next day. For multi-day efforts this is an indispensable skill that I believe all successful developers eventually grok.
25 years of development, 20 teaching at the university
Both worlds conclude the same:
Estimation is a waste
In software as in everyday life, estimating time is hard. For software in particular my typical response to "how long will it take?" type questions is:
By this point their eyes glaze over and they go, "number out of a hat is fine, I just need to put some numbers on a roadmap for my presentation to the board next week!" at which point I oblige them duly with a number that's on purpose a bit bloated and everyone is happy. No expectations are broken, no business loss occurs and developers are not flogged to go "faster"!
I have also found that once an engineering effort is underway, keeping people in the loop about progress or even impedances every sprint via show and tells and demos, is the most effective way to have them stop asking such questions to begin with.
Hello Yogini! I completely agree with the insights shared in your article. As a developer, it can be a challenging task to estimate the time required to complete a particular task accurately. By breaking down tasks into smaller, more manageable parts, using historical data to inform estimates, and accounting for unexpected delays or setbacks, developers can improve their ability to estimate development time and deliver high-quality work to their clients. I really appreciate the practical tips and techniques provided in this article on how to estimate software development time. Thank you for sharing this informative post with the development community!
Practical principles like the ones you shared here help!
My colleagues and I have tried to make the art of practical effective estimation a lot more accessible in Twigflo.com by applying principles from the popular book “ultra forecasters — the art and science of prediction”.
A lot of good ideas here! For me, padding my estimate has been a huge win. Combining that with assessing how long a task took (and maybe what about it made it take longer) has helped me provide estimates that I either meet or beat.
At the beginning of my first project I was pretty bad at time estimation, but it got better over time and when I was aware of tooking all impediments into account, like the server often was down, deployment takes about an hour where I check the first time if my code is still running as expected or even for the first time seeing it run; Sudden more important tasks were coming up, meetings.
After a while I multiplicated my estimation by 2 or 3 and it was more precise to make the PM happy.
Too often I have found myself an a situation where a customer or manager wants a list of tasks/activities for a project or a change requirement with an estimate of each task/activitiy giving a total.
That almost always fails in my experience. We just dont know what the future will give, this quote kind of nails the problem; )
"..We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know."
RE: estimations as a team leader- I usually "estimate" (and I use the term loosely here) first by using a relative scale i.e. 1-5, 1-10, and then when planning a work period out for someone I'll budget an amount of time depending on the developer. The time budget isn't something that the client should be basing expectations on or even looking at, it's a way to curb developers going off the rails and banging on the same thing for 3-4 days.
The key is once they hit their hourly "budget" they should submit what they've done either because it's done, or because they need more guidance from an alternative mind to get nudged in the right direction or overcome some perceived difficulty. It most importantly forces them to take a break and work on something else- often this will get them "unstuck" by itself.
These things can happen no matter what the team structure, but I find it most common when dealing with contracted developers. Their incentive structure isn't naturally such that it emphasizes things like limiting time spent on a task, unless maybe they happen to be extremely self motivated and overqualified.
Not sure but estimation can be stressful part, sometimes you get something you don't even know how it will be done.
Breaking task into smaller parts sounds promising. Thanks a lot
Thanks for the tips. Very helpful. It is really good idea to split a task into multiple smaller task.
For me, adding stemimate on my task makes me more stressfull. Although Im finishing the task early, but my health not good.