Skip to main content

Task estimation mechanism

Last post 08:26 am August 23, 2017 by Ian Mitchell
4 replies
04:48 am August 22, 2017

If a User Story is estimated in Story points then how are task estimated it is no of hours or days or some points mechanism.


03:34 pm August 22, 2017

Why would you need an estimation in hours for the relevant tasks of a user story?


09:21 pm August 22, 2017

Agreed.   There is indeed value in identifying the tasks needed to deliver the story solution, but if you've already estimated the story, why do you need to estimate the tasks?   Relative estimation is designed to avoid time-based estimation.   There is plenty of evidence demonstrating how poorly those in IT estimate time-wise.   Therefore, there is little if any value in the additional effort expended to provide time estimates for underlying tasks.

 

Relative estimation is basically placing stories into different-sized categories.  And Story Points do not add up to other higher story points - don't try to do this!   Think X-Large, Large, Medium, Small, and X-Small.   How many of the smaller "relative" sizes add up to a larger story?   Doesn't make sense, does it?

 

As you can see, it is rather pointless (no pun intended) to relatively estimate tasks.   And while some may prefer to provide a time-based estimate on tasks, it is my opinion that it is a wasteful exercise. 

 

A significant benefit to relative estimating is that it is quick and reasonably accurate, especially compared to traditional estimation practices.   Do not over-complicate the approach.


06:12 am August 23, 2017

As you can see, it is rather pointless (no pun intended) to relatively estimate tasks.   And while some may prefer to provide a time-based estimate on tasks, it is my opinion that it is a wasteful exercise. 

This is in line with my first-hand experiences. Our team dropped time-based task estimation back in April because the estimates were always waaay off and provided no value to the process or the product.


08:26 am August 23, 2017

During a Sprint it should be possible to sum the amount of work thought to be remaining in the Sprint Backlog, preferably by means of evidence, such as stories and/or tasks actually completed.

If the selected Product Backlog items (e.g. stories) are sufficiently granular to provide this transparency, then no further sizing of work in the team's plan may be necessary. If not, then the more detailed work in the plan (e.g. tasks) may need to be sized. Since it is comparatively fine-grained, time-based sizing of this work may be viable. Tasks, for example, are frequently sized in hours.


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.