Differences

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

--- what_is_the_basis_of_our_estimating_process [2019/01/16 10:02] – Called out relative estimation hpsamios
+++ what_is_the_basis_of_our_estimating_process [2020/11/02 10:49] (current) – Cleaned up for readability hans
@@ Line 1: / Line 1: @@
 ====== What is the Basis of Our Estimating Process? ======
-The basis of the estimating process is "Team based relative size estimates" or "Story Point estimation" to estimate User Stories (the requirement). This means:
+The basis of the estimating process is "Team based relative size estimates" or "Story Point estimation" to estimate User Stories (the need). This means:
-  * We do relative size estimates (how big something is in relation to something else) estimates, not duration (how long something takes).
+  * We do relative size estimates (how big something is in relation to something else), not duration estimates (how long something takes).
-  * We use a team based approach to estimation such as planning poker or affinity (triangulation based) estimation
+  * We use a team based approach to estimation such as planning poker or affinity (or triangulation) estimation
   * We have the people (in other words "the Team") doing the work doing the estimates
   * We use the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) for estimating
@@ Line 12: / Line 12: @@
 ===== Relative Estimates =====
-<WRAP Box>If two work items are they same size, will they always have the same estimate?</WRAP>
+>If two work items are the same size, should they always have the same estimate?
-It is worth delving into the notion of a relative size estimate for a moment. Most traditional estimates are based on duration, and that leads to a whole bunch of problems (see [[what_is_the_purpose_of_estimation|What is the Purpose of Estimation?]] for more information). But it is worse than that. If you have two pieces of work to do, both of which you think will take about 20 hours to complete, but the first piece of work is straight forward, while the second is in an area where there is a traditionally a lot of problems, should these items have the same estimate? No, you'll probably want to put some level of buffer in place to offer a more realistic estimate in the the for the second piece of work. This is another reason to move away from pure time based estimates.
+It is worth delving into the notion of a relative size estimate for a moment. Most traditional estimates are based on duration ("it will take about 20 hours"), and that leads to a whole bunch of problems (see [[what_are_the_problems_with_estimation|What Are The Problems with Estimation?]] for more information). But it is worse than that. If you have two pieces of work to do, both of which you think will take about 20 hours to complete, but the first piece of work is straight forward, while the second is in an area where there is a traditionally a lot of problems, should these items have the same estimate? No, you'll probably want to put some level of buffer in place to offer a more realistic estimate for the second piece of work. This is another reason to move away from pure, absolute time based estimates.
-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 single Team member'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.
+>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.
 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.