Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Why estimate by product and not by task?

Last post 04:51 pm March 24, 2022 by Karinna Tomeo
4 replies
01:21 pm March 18, 2022

What are the advantages of estimating a story considering its total construction instead of estimating by tasks that make up the story and then adding them to have an estimate of the story?

10:57 pm March 18, 2022

None. My concern would be why Developers thought they had to make a false and unduly prescriptive choice about their estimation approach.

02:43 pm March 21, 2022

I agree with @Ian.  The team should decide how estimation works best for them.  There is nothing in the Scrum Guide that addresses how a team estimates.  In fact, the word "estimate" is not even in the current revision.  The only tangental mention is this statement. 

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

To know if something "can be Done by the Scrum Team within one Sprint" implies some type of estimation. 

02:44 am March 23, 2022

Estimating by story points is better than by task.


1. story points is estimate by the Scrum team not just by the developer.

2. Maybe first-time story points is not so accurate at one Scrum team, but it will become more and more accurate later with the increase of teamwork times.

3. if we estimate by story point(product), we can talk it with po/Scrum master/PM/Clients, and estimate the story scales.

01:19 pm March 24, 2022

Thanks to everyone for your replies. They helped me a lot.