Hi, I've been a professional developer and DevOps engineer for 20 years 🤓. I share original content from diverse real-world production experiences through monthly blog posts.
For me estimating is a waste of time, counting the user stories done by week is a better way of projecting. That being said, let's be realistic, changing the world is not easy !
Some advice :
Track time for your tasks of the past, to have references (and it helps to negociate with managers).
Compare to tasks already done. Ideally by yourself, but by others too, it can work, depending of your respective experiences. More that this one, less than the other one, is easier than from scratch. If you do not known, compare only the testing effort, it is a great indicator.
Always tells an estimation rounded to a bigger number. when starting in this field, we think that managers want the task as quickly as possible, but in fact, they prefer the most reliable response, even if it is a bigger number.
Use Fibonacci estimation : this way you will not waste your time figuring if it is 6 or 6.5 days. It is more than 5, so the answer is 8.
If it is too much (for you or your manager), break down into smaller tasks.
I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
This. The Fibonacci estimation seems brilliant. Could you talk a bit more about how you have applied it in the past? I'm genuinely curious how it went.
Hi, I've been a professional developer and DevOps engineer for 20 years 🤓. I share original content from diverse real-world production experiences through monthly blog posts.
This is widely used in software. You will find this everywhere on internet.
Back in the days, when we were estimating in our teams, before #NoEstimate, I used it mostly in 2 occasions :
In backlog refinement, when everyone is "guessing". This is a common usage to only use Fibonacci.
During Extreme Quotation sessions : you estimate a whole bunch of US by putting them in columns, each one with a Fibonacci size, and an US from the past as reference.
When I was a junior developer, I did not know yet this agile practices, so I estimated without Fibonacci.
I like the Fib estimation approach as it is used to determine the complexity of a task more so than the time it would take it is easy to reason that if a task is less complex it should take less time and vice versa. There are cases where a task can inflate in complexity but this is usually an experience thing, the more experience the less scope creep occurs when spec'ing out work
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, I've been a developer for 18 years.
For me estimating is a waste of time, counting the user stories done by week is a better way of projecting. That being said, let's be realistic, changing the world is not easy !
Some advice :
Cool @bcouetil . Thanks for the advice!
This. The Fibonacci estimation seems brilliant. Could you talk a bit more about how you have applied it in the past? I'm genuinely curious how it went.
Thanks.
This is widely used in software. You will find this everywhere on internet.
Back in the days, when we were estimating in our teams, before #NoEstimate, I used it mostly in 2 occasions :
When I was a junior developer, I did not know yet this agile practices, so I estimated without Fibonacci.
I like the Fib estimation approach as it is used to determine the complexity of a task more so than the time it would take it is easy to reason that if a task is less complex it should take less time and vice versa. There are cases where a task can inflate in complexity but this is usually an experience thing, the more experience the less scope creep occurs when spec'ing out work