User Tools

Site Tools


what_is_the_basis_of_our_estimating_process

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
what_is_the_basis_of_our_estimating_process [2019/01/16 10:06] – Emphasis hpsamioswhat_is_the_basis_of_our_estimating_process [2019/01/16 10:06] hpsamios
Line 18: Line 18:
 One thing that often confuses people who are used to traditional task based estimates is that the resultant estimate is a Team's view of how big this item is. When we say the estimate is a "3", we are really saying that the Team's view of this piece of work is that it is a "3". In particular, it is not a person on the Team's view. When starting, many Teams fall into the trap of saying "There are design, implementation, and testing components of this piece of work. George will do the design so what do you think the estimate is for the design piece ... Jenny will implement, so what do you think the estimate for the implementation piece is ..." and then just sum up the results. In Agile the unit of execution is the "Team" and so the estimates indicate the size of work for the Team not the individuals on the Team. Sure the time to "design" and "implement" are part of that. But to deliver the value represented by the Story the Team might, for example, want to pair implementation and testing as they do the design to improve the design. Or the Team might find that testing might need an "all hands on deck" approach to assure quality. What we are estimating is the Team's ability to deliver value. One thing that often confuses people who are used to traditional task based estimates is that the resultant estimate is a Team's view of how big this item is. When we say the estimate is a "3", we are really saying that the Team's view of this piece of work is that it is a "3". In particular, it is not a person on the Team's view. When starting, many Teams fall into the trap of saying "There are design, implementation, and testing components of this piece of work. George will do the design so what do you think the estimate is for the design piece ... Jenny will implement, so what do you think the estimate for the implementation piece is ..." and then just sum up the results. In Agile the unit of execution is the "Team" and so the estimates indicate the size of work for the Team not the individuals on the Team. Sure the time to "design" and "implement" are part of that. But to deliver the value represented by the Story the Team might, for example, want to pair implementation and testing as they do the design to improve the design. Or the Team might find that testing might need an "all hands on deck" approach to assure quality. What we are estimating is the Team's ability to deliver value.
  
-<WRAP>In Agile the unit of execution is the "Team" and so the estimates indicate the size of work for the Team not the individuals on the Team.</WRAP>+<WRAP Box>In Agile the unit of execution is the "Team" and so the estimates indicate the size of work for the Team not the individuals on the Team.</WRAP>
  
 For more information on the basis of the process see [[https://www.youtube.com/watch?v=MrIZMuvjTws|Planning Poker for Estimates from Mike Cohn]]. Affinity mapping is based on [[facilitation_-_play_pass_or_move|Play, Pass, or Move]] approach. For more information on the basis of the process see [[https://www.youtube.com/watch?v=MrIZMuvjTws|Planning Poker for Estimates from Mike Cohn]]. Affinity mapping is based on [[facilitation_-_play_pass_or_move|Play, Pass, or Move]] approach.
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/what_is_the_basis_of_our_estimating_process.txt · Last modified: 2020/11/02 10:49 by hans