Skip to main content

Should we or should we not estimate tasks?

Last post 11:49 am December 10, 2012 by Charles Bradley
10 replies
09:02 am December 6, 2012

Hello all!

This is my first post here ... and I would really like to get some opinions on this: What do you think about task estimation in ideal hours?

From my point of view, one task can be 2 ideal hours for 1 dev but lets say 4 ideal hours for a less experienced dev in the same team. How should they agree on a common estimation for the task?
And if they finally agree on the 2 ideal hours for the task (thinking probably that the experienced dev will implement it) but then the task has to be implemented by the less experienced dev (lets say the first one gets ill or there is some other reason he can not do it), wouldn't this estimation be a bit stresfull for the less experienced? Should he reestimate it to 4 hours?
I know that estimations are "estimations" and not a commitment that the task will really get done in 2 hours, but I've seen that there is still some pressure felt by the people having to implement the task ...

Would it be better to not estimate tasks at all? I think this might be also different from team to team, but .... what's your opinions?


02:54 pm December 6, 2012

Ileana,

Have you asked the team? If so, what do they want to do? What is your role on the team?

Task estimation in ideal hours is a valid way to create a Sprint Backlog. It is certainly not the only way to create a Sprint Backlog. Some teams don't estimate tasks, and some teams don't even create tasks at all. I won't go into the umpteen other ways to do it other than to say this: Generally speaking, using ideal hours is often useful for teams/orgs relatively new to Scrum who have a past using hours to estimate tasks. It also has downsides if the team is pressured in any way on their tasks, and if the team has too much waterfall type behavior.

As to your "less experienced vs. more experienced,"... this is an interesting one. I usually just tell teams to estimate all things for a mythical "average developer" on the team at Sprint Planning. Then, I also remind the team that they are free to re-estimate tasks at any time, so maybe when the person who picks it up "signs up" for it in the sprint. That person is now free to re-estimate it as soon as they pick it up. This can create some challenges for how you construct your Sprint Progress Monitor(burndown), but it's usually fairly easy to handle.

Some considerations, in addition to the questions above, that might indicate different advice would be...
Has the team attended Scrum training? If so, how recently?
How new is the team to Scrum?
How do they handle this challenge now?
Is your team meeting their Sprint forecasts?
Does your team do the typical sprint planning where most of the sprint is planned out in Sprint planning?
How often does your team currently re-estimate tasks?
* For instance, some teams re-estimate every day(I call this the "Daily Task Re-estimation" pattern), while others make sure all of their tasks are small and they generally only re-estimate if there is a large change in estimates(I call this the "Micro-Tasks" pattern).

Anyway, hope this helps!


05:14 pm December 6, 2012

Hi Lleana

Do your tasks stand by themselves, or are they tasks that are identified during sprint planning in order to satisfy user stories?

Some teams estimate user stories but not the tasks. Others estimate the tasks but not the stories. Some use points and others hours. Others do a mix. In some cases they do neither, and only track the actuals!

You don't mention whether or not stakeholders outside the team expect estimates. Some, such as customers or budget holders, often want to know *when* features will be delivered and how much they are likely to cost. For a project with an emergent scope, getting the team to estimate the work on the backlog provides a way to do this.

However, there is another advantage to estimation - it gets the team talking. The issues you mention (different team members having different views) is exactly the sort of debate you want to promote so that requirements can be understood. Techniques like planning poker can assist this further.

Often though, a team may prefer to estimate using "relative sizing" as opposed to estimates based on time. It can be more realistic to compare tasks (or user stories) against each other in terms of their complexity rather than attempting to say how long each will take. Also, time based estimates tend to become less reliable the higher they go, and they can lead certain stakeholders to expect every hour to be accounted for. But whatever you choose, don't forget that a team has a duty to regularly update their estimates throughout a sprint, and to renegotiate the scope with the product owner if it all starts to look too much.


01:41 am December 7, 2012

However, there is another advantage to estimation - it gets the tea


Abolutely agree with you. Often it's the most important benefit of the estimating.
Only mature Scrum teams (usually hyper-productive ones) would be able to create so small stories with so similar size that it would not be necessary to go on with breaking them further into the tasks.


06:38 am December 7, 2012

Illya,



Only mature Scrum teams (usually hyper-productive ones) would be able to create so small stories with so similar size that it would not be necessary to go on with breaking them further into the tasks.



I tend to agree. I have documented what I call the "Micro-stories" pattern further here:
http://www.scrumcrazy.com/User+Story+Pattern+-+Micro+Stories


06:45 am December 7, 2012

Hi again ... and lots of thanks for your comments.

During the sprint planning meeting we are estimating User stories in story points using planning poker and this works very well (we have debates to clarify lots of stuff) .. .then we have the task splitting which also works well. We don't estimate tasks. We don't need to and until now we've been just fine with that .. .I don't see why we would change that.

The question related to the ideal hours estimations was because of all the articles I've read about it. I really think that we (my team) don't need them and I was trying to figure out why other teams do and why this ideal hours stuff works for them. I have also talked to the team about it and they came with the idea that this estimations would make them feel stressed to be sticking to the estimation ... so, for us, there are no ideal hours estimations.


07:04 am December 7, 2012

Ileana,

Your strategy is also a viable one, if it's working. Does your team usually finish all the stories it plans for a Sprint? Do you track the Sprint progress via a story point burndown?

In terms of the background about ideal hours -- up until about 2010, the Scrum Guide strongly suggested estimating tasks in ideal hours, but that guidance became more flexible gradually until 2011, the Scrum Guide only requires that a) there is a Sprint Backlog (some sort of plan for the sprint), and b) that the work remaining in a sprint is summed and monitored daily. More on that Scrum Guide change here:
https://www.scrum.org/About/All-Articles/articleType/ArticleView/articl…



08:16 am December 7, 2012

Hi Charles,

We are tracking the progress via story point burndown .... the velocity of the team became a stable one I would say (of course there is not equal story points done during each sprint, but the differences are pretty small). We are trying to focus on finishing one user story before starting another one (whenever this is possible). I can't say we always finish everything we plan for a sprint .... but we're still learning.


11:06 am December 7, 2012

Ileana,


We are trying to focus on finishing one user story before starting another one (whenever this is possible)



^^ A very admirable pursuit!! Swarming can be a wonderful practice!

It sounds like converting to ideal task hours would not serve your team well at this time. The current technique seems to be working fine(assuming you're doing all the other good Scrummy things, of course), and the technique is very much in line with Scrum principles.

Congrats! And best of luck with your team!


06:41 am December 10, 2012

Yeah ... I think we are happy with no ideal task hours estimation.
Thanks Charles and very interesting stuff on scrumcrazy.com .
And thanks to everyone for your good comments!


11:49 am December 10, 2012

Ileana,

As I look over my own posts, always looking to improve myself, it dawns upon me that I probably should have mentioned this from the Scrum Guide(section on Sprint Planning Part Two):
"Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or
less by the end of this meeting."

My guess is that your tasks are probably at or around that size, so no big deal. I just wanted to mention it primarily because others may come later and read this thread.

Best of luck to you and your team, and please do not hesitate to come back! The people on this forum truly enjoy helping others!


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.