estimating: Add chapter details
authorChase Maupin <chase.maupin@ti.com>
Mon, 13 May 2013 19:11:09 +0000 (14:11 -0500)
committerFelipe Balbi <balbi@ti.com>
Wed, 15 May 2013 18:27:17 +0000 (21:27 +0300)
* Fill out the estimating chapter to cover:
    * Why Story Points vs. Hours
    * The online tool we can use
    * Upgrading stories to epics

Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
estimating.tex

index 57d0c891fd5a7d0082bc6e5523371e6c5c3c3ee0..2815ff9d041f5b8f070572a243a23300f87988cd 100644 (file)
@@ -3,17 +3,96 @@
 %% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
 %%                                                                       %%
 %% Author: Felipe Balbi <balbi@ti.com>                                   %%
+%% Author: Chase Maupin <chase.maupin@ti.com>                            %%
 %%                                                                       %%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \chapter{Estimating}
 \label{chap:estimating}
 
-\section{Tasks Are Broken, Now What ?}
-\label{sec:tasks-are-broken-now-what}
+\paragraph{}
+A large portion of time in Scrum is spent estimating the level of effort
+required for a given story.  This is obviously given so much time because
+without a proper estimation of the effort required to complete a story the
+scrum team is unable to commit to which items can be completed in a single
+sprint.
+
+\section{Story Points vs. Hours}
+\label{sec:story-points-vs-hours}
+
+\paragraph{}
+When estimating the size and level of effort for a story it is often useful
+to use \textbf{Story Points}.  Story points are a relative scale that
+represents how much effort is required to complete a particular story.
+Story points are expressed as relative values because it is easier for
+people to rank items in relation to one another.  For example if you were
+asked how many shovels of dirt and how much time it would take to dig a
+20x20 foot hole 18 inches deep could you give an answer that was any better
+than a wild guess?  What if I told you that digging a 20x20 foot hole 12
+inches deep took 1000 shovels of dirt and 2 days.  With this information you
+could make a relative estimation of the first task.  So now you could say that
+it should take about 1500 shovels of dirt and 3 days.  It is much easier to
+describe something as harder or easier than some known task and how much
+harder or easier it seems to be.
+
+\paragraph{}
+Another reason to use story points instead of other metrics such as
+hours or ideal hours is that in these cases the metric itself starts to
+distract from the effort estimate.  For example if you were asked to dig
+the hole about and tell roughly how many hours it would take, you might
+start thinking about non-related details like whether you would need to
+take time to go buy a shovel, will you need a lunch break, what about your
+doctor's appointment on Tuesday?  Hours touches people at a "real" level
+and instead of keeping them focused on the relative size and complexity of
+the story they start worrying about things that can distract them.
+
+\paragraph{}
+Further, hours leads to a desire to be precise.  If you say a task is going
+to take 60 hours you will likely feel the need to make sure you can get the
+task done in exactly 60 hours.  But for a tasks that takes 60 hours, is 64
+really that much more?  Is 56 that much less?  So why not give it a set of
+story points that say it is a task that is \textit{about} 60 hours and
+not worry about the small details.
+
+\paragraph{}
+There are other ways to estimate such as using shirt sizes like small, medium,
+large, x-large.  as you will see in section \ref{sec:estimating-tool} we will
+use a tool that uses a rough fibonacci sequence to allow concurrent estimation
+for teams in a distributed environment.
+
+\section{Estimating Tool}
+\label{sec:estimating-tool}
+
+\paragraph{}
+One of the important things about estimating backlog items is the idea of
+the simultaneous reveal of the estimation.  This is important because it
+allows everyone to put out their estimation without being influenced by
+the person(s) before them.  This is easy to do when everyone is in one
+location but how do you do then on distributed teams where people may
+be interacting with each other over the phone?
+
+\paragraph{}
+Luckily for us the fine people of "Mountain Goat Software" have an online
+version of planning poker which allows the entire team to participate in
+the estimation effort while still having the simultaneous reveal capability
+that keeps people from having their opinions jaded by others.  This tool
+can be found at \url{http://www.planningpoker.com/} and you can create
+a free account.
+
+\paragraph{}
+This tool allows uploading stories, discussing them, having each team member
+give an estimate of the level of effort with a simultaneous reveal.  If the
+estimates do not match then the team can further discuss the item and re-vote
+until a consensus is reached.  At the end of the planning session the items
+and their estimates can be exported.
 
 \section{Estimated Task Is Too Large To Fit In One Sprint}
 \label{sec:estimated-task-is-too-large}
 
-\section{Implementing, At Last}
-\label{sec:implementing-at-last}
+\paragraph{}
+Sometime during estimation the story may be too large to fit into a single
+sprint.  This may be because of some ambiguity about what the story entails,
+or just that it simple is too much based on the team's velocity.  If this is
+the case you should promote the story into an epic and then start working to
+break this epic up into smaller stories that can be estimated to fit within
+a single sprint.  For more details see chapter \ref{chap:grooming}