estimating.tex

   1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   2 %%                                                                       %%
   3 %% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
   4 %%                                                                       %%
   5 %% Author: Felipe Balbi <balbi@ti.com>                                   %%
   6 %% Author: Chase Maupin <chase.maupin@ti.com>                            %%
   7 %%                                                                       %%
   8 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   9
  10 \chapter{Estimating}
  11 \label{chap:estimating}
  12
  13 \paragraph{}
  14 A large portion of time in Scrum is spent estimating the level of effort
  15 required for a given story.  This is obviously given so much time because
  16 without a proper estimation of the effort required to complete a story the
  17 scrum team is unable to commit to which items can be completed in a single
  18 sprint.
  19
  20 \section{Story Points vs. Hours}
  21 \label{sec:story-points-vs-hours}
  22
  23 \paragraph{}
  24 When estimating the size and level of effort for a story it is often useful
  25 to use \textbf{Story Points}.  Story points are a relative scale that
  26 represents how much effort is required to complete a particular story.
  27 Story points are expressed as relative values because it is easier for
  28 people to rank items in relation to one another.  For example if you were
  29 asked how many shovels of dirt and how much time it would take to dig a
  30 20x20 foot hole 18 inches deep could you give an answer that was any better
  31 than a wild guess?  What if I told you that digging a 20x20 foot hole 12
  32 inches deep took 1000 shovels of dirt and 2 days.  With this information you
  33 could make a relative estimation of the first task.  So now you could say that
  34 it should take about 1500 shovels of dirt and 3 days.  It is much easier to
  35 describe something as harder or easier than some known task and how much
  36 harder or easier it seems to be.
  37
  38 \paragraph{}
  39 Another reason to use story points instead of other metrics such as
  40 hours or ideal hours is that in these cases the metric itself starts to
  41 distract from the effort estimate.  For example if you were asked to dig
  42 the hole about and tell roughly how many hours it would take, you might
  43 start thinking about non-related details like whether you would need to
  44 take time to go buy a shovel, will you need a lunch break, what about your
  45 doctor's appointment on Tuesday?  Hours touches people at a "real" level
  46 and instead of keeping them focused on the relative size and complexity of
  47 the story they start worrying about things that can distract them.
  48
  49 \paragraph{}
  50 Further, hours leads to a desire to be precise.  If you say a task is going
  51 to take 60 hours you will likely feel the need to make sure you can get the
  52 task done in exactly 60 hours.  But for a tasks that takes 60 hours, is 64
  53 really that much more?  Is 56 that much less?  So why not give it a set of
  54 story points that say it is a task that is \textit{about} 60 hours and
  55 not worry about the small details.
  56
  57 \paragraph{}
  58 There are other ways to estimate such as using shirt sizes like small, medium,
  59 large, x-large.  as you will see in section \ref{sec:estimating-tool} we will
  60 use a tool that uses a rough fibonacci sequence to allow concurrent estimation
  61 for teams in a distributed environment.
  62
  63 \section{Estimating Tool}
  64 \label{sec:estimating-tool}
  65
  66 \paragraph{}
  67 One of the important things about estimating backlog items is the idea of
  68 the simultaneous reveal of the estimation.  This is important because it
  69 allows everyone to put out their estimation without being influenced by
  70 the person(s) before them.  This is easy to do when everyone is in one
  71 location but how do you do then on distributed teams where people may
  72 be interacting with each other over the phone?
  73
  74 \paragraph{}
  75 Luckily for us the fine people of "Mountain Goat Software" have an online
  76 version of planning poker which allows the entire team to participate in
  77 the estimation effort while still having the simultaneous reveal capability
  78 that keeps people from having their opinions jaded by others.  This tool
  79 can be found at \url{http://www.planningpoker.com/} and you can create
  80 a free account.
  81
  82 \paragraph{}
  83 This tool allows uploading stories, discussing them, having each team member
  84 give an estimate of the level of effort with a simultaneous reveal.  If the
  85 estimates do not match then the team can further discuss the item and re-vote
  86 until a consensus is reached.  At the end of the planning session the items
  87 and their estimates can be exported.
  88
  89 \section{Estimated Task Is Too Large To Fit In One Sprint}
  90 \label{sec:estimated-task-is-too-large}
  91
  92 \paragraph{}
  93 Sometime during estimation the story may be too large to fit into a single
  94 sprint.  This may be because of some ambiguity about what the story entails,
  95 or just that it simple is too much based on the team's velocity.  If this is
  96 the case you should promote the story into an epic and then start working to
  97 break this epic up into smaller stories that can be estimated to fit within
  98 a single sprint.  For more details see chapter \ref{chap:grooming}