How to estimate a task?

Currently, I'm working as a web developer. I'm not good at estimating a task (or) project's sprint tasks. Each sprint may have a list of tasks. How to properly estimate these tasks. Looking for help. Thanks in advance!

Comments

[Benoit COUETIL 💫]

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 :

• 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.

[Shailen Naidoo]

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

[tq-bit]

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.

[Benoit COUETIL 💫]

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 :

• 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.

[Ajithkumar P S]

Cool @bcouetil . Thanks for the advice!

[Phil Ashby]

Are you estimating only your work, or are you estimating as a team? Are you estimating in specific units or finding out how many tasks will fit in the sprint? I ask since the dynamic changes quite a bit:

1/ Just you: I would apply a task breakdown (aka divide & conquer) approach to understand enough that you are confident in the estimate, but without doing all the actual design work, eg: apply your previous experience and familiarity with the product / codebase to help you identify the scope of a task / change (the affected components), then your experience in making changes to those components (well-understood, familiar, unfamiliar, unknown). You now have a picture of how many components, and how well you known them, so you make estimates of each change to the components (often simply a fixed value based on understanding) and add them up (in your chosen units).

2/ With a team: My previous team experience: each team member individually chooses a 'size' value for a task (small - eg half a day, medium - eg: 1-2 days, large - eg: 1 week, too large - whole sprint), then the team comparing those and discovering if there was agreement or that sizing was variable, demonstrating a poorer understanding of the task. For tasks where sizing was matched, a team member would volunteer to take the task on, adding it to their sprint allocation (unless they were out of capacity), for poorly understaood tasks, the team would discuss the scope and apply a similar approach as above to get to a size. Often these more complex or less understood tasks would be shared between pairs of people to reduce risk and improve understanding.

In all cases - I hope you are able to discuss priorities with your team / product owner(s) to ensure that nobody takes on too much in a sprint (or worse, is 'given' too much without negotiation ability), that the team stays healthy and that you get to review how your agile process is working for the team and the company!

[Ajithkumar P S]

Thanks for your descriptive comment! As of now I'm trying to estimate my work only.

[Piotr]

This is a hard and controversial topic. I don’t agree with people saying estimating is worthless.

From my experience on both sides - as a manager as well as the developer, I see many benefits to them. I know this is not the answer to your question but I would like to address that first.

Wrong estimates mean generally one of four things:

• Poorly described and scoped User Stories. If US is not separated into clear, actionable tasks with clearly defined scope/deliverabilities than well… There is no sense to estimate how long it will take to prepare a billing module in a banking app, but estimating adding a new modal, with 3 actions (of which 2 are developed) and a content based on the integration is a different story. Of course estimating all tasks does not mean that epic level will be „estimated automatically”. You still need to accomodate the unplanned, time for meetings, people being off, sick etc.

• Lack of expertise - sometimes you just don’t have skills and knowledge to provide meaningful estimates. Even worst, you may not have in your org anybody who has - then yes, estimates is closer to guess work which still provides you a lot of important info.

• Lack of ownership - well, sometimes people just don’t give a shit about their job or tasks enough to actually provide meaningful estimates.

• A lot of technical debt - sometimes it does not matter how much everyone tries, if your code base is terrible quality and making a small change requires a lot of effort then well… you have bigger problems than estimates

Now, as the name suggests „estimates” are „estimates” and nothing more. They state how much we think something will take, not how much it will take. I found that usually 10% variance is a good result. 25% in immature team with good technical and business leadership. Above that it means your team has problems which should be investigated and actioned.

Now when it comes to the tips:

• Don’t ever think it terms or User Story, think about actual tasks. Specific things you have to do. If you are not sure what has to be done spend some time figuring it out. If anything is unclear refine as much as needed. Break down US into tasks, still to big? Subtasks. They don’t have to be on the board, they are a tool for you to understand the task

• Ask developers of higher or similar level. If there is a step which seems complicated, maybe they have done it before? They did? Well maybe they will help to estimate how much it will take you? Maybe they even have something that can be reused or they can support you to make the process easier and quicker

• Look at similar tasks, but done by people of similar skill level or you in the past.

• Don’t be afraid to provide inaccurate estimates, if you are doing your best and using all available resources to make them best you can. There will be always things you may not anticipate, if you are not a leader, you shouldn’t be to be prepared perfectly and know most of the things. Well even if you are leader, you cannot know everything.

• Remember that 1 MD of a task development is a 1 MD of development. If you spend 2h a day on meetings, 1h on networking, now the due date is in 2 days time

Now the final thought: Estimate, everything, if you don’t want to do it in exact time, do it in Fibonacci (though I still prefer the actual time). Why? It gives you a valid information about the tasks for the future and it should give your leadership a lot of other information - about their team abilities, complexity of the project, technical debt, sometimes even about things like ways of working, too much bureaucracy etc.

[Ajithkumar P S]

👌

[Randall]

One of my favorite tips is to never give a single estimate: give two, a 50% confidence estimate and an 80% confidence estimate.

As a rule of thumb the 80% estimate can just be double the 50% estimate, though YMMV.

Doing it this way draws attention to the inherent inaccuracy of estimating, and gives you margin for being wrong. Even if you end up going over your 80% confidence estimate, you were only 80% confident in hitting that. It happens.

But as you go, you can work on dialing things in, so that you stay under your 80% confidence estimate roughly 80% of the time. You'll never be perfect.

[Ben Halpern]

Keep your expectations reasonable, nobody’s great at this

[Ajithkumar P S]

Hmm thanks @ben!

[Rense Bakker]

Estimations are generally useless, because work just needs to be done and an arbitrary point system doesn't change anything about that. It's just a convenience metric for product owners to throw sand in the eyes of higher management and then blame the developers when it backfires. Or if you have evil team members, it can be a way for them to make you look bad, by constantly challenging your estimates.

[Sirajul Muneer]

Try to split the task into smaller predictable chunks. If you feel some tasks are huge and would involve a lot of code change identifying how it can be split up is important. Once you get smaller tasks it would be much easier to estimate the task, story or epic. Rinse and repeat for some time, and later when you get a story or epic you might be able to relate it to your previous experience and provide a rough estimate. Still you would need to keep estimating and splitting tasks to validate your estimate and evaluate the team’s progress in a measurable way. If you prefer using Fibonacci, you can for example make a cut off point sbove which the task is complex and mist be split. I generally take 8 point and if a task is 8 or more, I won’t work on it until it is split up into smaller independent tasks.

[Ajithkumar P S]

Thanks for insightful info @sirajulm !

[Robert French]

A few great comments already!

Really there are three main reasons to estimate as a team. The first is to uncover where you’re not in alignment with one another on the effort required (I.e. Bill thinks it’s a 5 and Jill thinks it’s a 1 … likely you don’t understand the work the same). Second is so the team can say “that 5 is too big and we should likely split the work smaller”, this helps the whole team move towards small, similar sized work so you can stop counting the points and get to the story count in a meaningful way (remember that estimates support velocity, so velocity can support the use of points), when the team shifts to counting stories, you can use forecasting and measure throughput instead, monte-carlo predictive modelling is more precise. Last, having an estimate can sometime help the PO prioritize the work.

I often remind folks that the value in doing estimate work (as a team) is in the discussion and the understanding of the work, not the numbers that make up the result. Good collaborative discussion is real work and can save a ton of waste.

[Ajithkumar P S]

👏

[Red Ochsenbein (he/him)]

Estimates are pretty worthless. If you can accurately estimate your tasks, then you're not automating enough. Other than that estimates only tell you one thing: if you used more or less time than estimated.

If the management enforces estimates you can be pretty sure those will turn into self-fulfilling prophecies.

[Fatemeh Paghar]

Estimating a task means figuring out how long it will take to finish it. To do this, you can break the task into smaller parts, like steps in a recipe. Think about similar tasks you've done before to get an idea of how long it might take. Talk to your team members to get different opinions and insights. Consider any problems that might come up and add some extra time for them. Look at how long similar tasks took in the past to help you make a good guess. It's important to keep learning and improving your estimation skills based on what you've experienced before. Stay open to changes and talk with your team to make sure everyone is on the same page.