group estimate top-down estimate

46 views
Skip to first unread message

dotnetguy

unread,
Mar 8, 2017, 4:10:57 AM3/8/17
to Scrum Alliance - transforming the world of work.
Everyone knows top-down estimates are bad. Scrum uses team-based estimates but what if the majority of the team votes for one estimate but the person actually responsible for doing the work votes higher and says that the team estimate is too low and says they can't commit to it? If the majority votes a certain way but the person doing the work votes higher then wouldn't going with the majority vote be equivalent to a top-down estimate?

Howard Sublett

unread,
Mar 8, 2017, 6:21:53 AM3/8/17
to scruma...@googlegroups.com
There is so much here....

But, in short, team based estimates are because the TEAM is responsible for getting the work done.

If one individual is responsible for getting the work ( story) done, there is a disconnect in how scrum teams work, or an issue with single code ownership, or an issue in how the story is written.

Howard Sublett
Cell: 501.622.7929
Sent from my iPhone

> On Mar 8, 2017, at 3:10 AM, dotnetguy <andrew.d....@gmail.com> wrote:
>
> Everyone knows top-down estimates are bad. Scrum uses team-based estimates but what if the majority of the team votes for one estimate but the person actually responsible for doing the work votes higher and says that the team estimate is too low and says they can't commit to it? If the majority votes a certain way but the person doing the work votes higher then wouldn't going with the majority vote be equivalent to a top-down estimate?
>
> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
> To post to this group, send email to scruma...@googlegroups.com.
> Visit this group at https://groups.google.com/group/scrumalliance.
> For more options, visit https://groups.google.com/d/optout.

David M. Babuder

unread,
Mar 8, 2017, 10:09:27 AM3/8/17
to scruma...@googlegroups.com
When we have divergent estimates, the person presenting the higher value should indicate their rationale for the higher estimate (likewise the person with the lowest).
If the team doesn't move on the consensus, it may be, as implied by the last comment, that the person isn't leveraging other team remembers effectively.

David Babuder
+1.440.646.6550
Ask me about Toast of Rockwell(this is a Rockwell Automation internal link)

Dan Rawsthorne

unread,
Mar 8, 2017, 10:24:36 AM3/8/17
to scruma...@googlegroups.com

Don't worry. You don't commit in scrum... and the reason we estimate is to have the discussion, not get an estimate... just sayin'...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work
Download our free eBook, Scrum 101: a Pocket Guide

Ron Jeffries

unread,
Mar 8, 2017, 10:58:59 AM3/8/17
to scruma...@googlegroups.com
I do hate to agree, but I pretty much do. :)

On Mar 8, 2017, at 10:24 AM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Don't worry. You don't commit in scrum... and the reason we estimate is to have the discussion, not get an estimate... just sayin'...


Ron Jeffries
ronjeffries.com
Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better. 
Of course you might plummet to the earth and die, but probably not: you were made for this.

Tom Mellor

unread,
Mar 8, 2017, 12:06:23 PM3/8/17
to Scrum Alliance - transforming the world of work.
It is hard to do something you hate to do. Which is usually the case with estimating. Steve McConnell, who actually wrote the book on software estimation, told me at the Seattle Scrum Gathering that an estimate by rationale must be a range. If it's a number, it's a target. Howard is correct, of course: we forecast work we can do as a team, not as individuals.

Rafał Konieczny @ alldone.io

unread,
Mar 13, 2017, 1:07:49 PM3/13/17
to Scrum Alliance - transforming the world of work.
How do you estimate your tasks? In hours? Days? Story Points? 
What are consequences of committing to estimate? Why this becomes an issue?
What is the difference in estimation between team and the individual?

In general estimation in Scrum have two purposes:
  • provide a base for team Velocity forecast that can be used as a guide by Product owner to plan his work and by the team to plan Sprints.
  • help better understand the scope of each story. If there is a difference in estimation between team members it should be discussed and consensus should be achievable. After all you should be estimating complexity of the story in relation to other items in the backlog. 
Estimate is always a guess. It will take as much as is needed to complete the story, that's why is so important to break stories into small, valuable chunks, and team works on most valuable ones. 

Alan Dayley

unread,
Mar 13, 2017, 2:36:16 PM3/13/17
to Scrum Alliance - transforming the world of work.
Did you want the questions answered or were the questions an introduction to your instructive statements?

Alan

--

MJ

unread,
Mar 13, 2017, 5:05:13 PM3/13/17
to scruma...@googlegroups.com
On Mar 13, 2017, at 10:05 AM, Rafał Konieczny @ alldone.io <rafal.k...@alldone.io> wrote:
>
> How do you estimate your tasks? In hours? Days? Story Points?

Are you talking about Product Backlog Items or Sprint Tasks? Sprint Tasks haven't been a required part of Scrum for years, and even when they were it was not recommended to have them bigger than a day. Anyway, who would need task estimates? What would they use them for?

If you were talking about Product Backlog Items, I suppose relative estimation is better. But the more important thing is to get them small enough that at least a few will fit inside a Sprint.

--mj

Rafał Konieczny @ alldone.io

unread,
Mar 13, 2017, 7:58:13 PM3/13/17
to Scrum Alliance - transforming the world of work.
Without answers to those questions is hard to help, other than with generic answers (that followed), but having details would allow us to finding more precise problem.

Michal Kadák

unread,
Mar 16, 2017, 10:47:14 AM3/16/17
to Scrum Alliance - transforming the world of work.
I'm always repeating to my team that we are sitting in the room to get prepared, to know the motivation and to be aware of possible troubles on the way. Sometimes they argue too much (like you said, the estimate is too low and they can't commit to it), but that's still a good thing. Some stories are harder than other and need more time to comprehend. Or 1on1 brainstorming right next day. Or spike. I wrote a short blog post about it:


Dňa streda, 8. marca 2017 10:10:57 UTC+1 dotnetguy napísal(-a):
Reply all
Reply to author
Forward
0 new messages