Forums

By posting to our forums you are agreeing to the Forum terms of use.
Should we or should we not estimate tasks?
Last Post 10 Dec 2012 10:49 AM by Charles Bradley. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Ileana
New Member
New Member
Posts:4
Ileana

--
06 Dec 2012 08:02 AM
    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?
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    06 Dec 2012 01:54 PM
    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!
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    06 Dec 2012 04:14 PM
    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.
    Illya Pavlichenko
    New Member
    New Member
    Posts:36
    Illya Pavlichenko

    --
    07 Dec 2012 12:41 AM
    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.

    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    07 Dec 2012 05:38 AM
    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+Stor...ro+Stories
    Ileana
    New Member
    New Member
    Posts:4
    Ileana

    --
    07 Dec 2012 05:45 AM
    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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    07 Dec 2012 06:04 AM
    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/articleId/94/The-New-New-Sprint-Backlog


    Ileana
    New Member
    New Member
    Posts:4
    Ileana

    --
    07 Dec 2012 07:16 AM
    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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    07 Dec 2012 10:06 AM
    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!
    Ileana
    New Member
    New Member
    Posts:4
    Ileana

    --
    10 Dec 2012 05:41 AM
    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!
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    10 Dec 2012 10:49 AM
    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!
    You are not authorized to post a reply.


    Feedback