life-cycle-of-story: Add creation of upstream stories
[ti-agile-manual/ti-agile-manual.git] / estimating.tex
1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2 %%                                                                       %%
3 %% Copyright (C) 2013 Texas Instruments Incorporated - %%
4 %%                                                                       %%
5 %% Author: Felipe Balbi <>                                   %%
6 %% Author: Chase Maupin <>                            %%
7 %%                                                                       %%
8 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
10 \chapter{Estimating}
11 \label{chap:estimating}
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.
20 \section{Story Points vs. Hours}
21 \label{sec:story-points-vs-hours}
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.
38 \paragraph{}
39 When using a relative effort system it is usually a good idea to have
40 at least one item of the simplest effort.  If you have that item to
41 serve as a baseline of an easy story that can be completed with minimal
42 effort, then you now have a starting point to compare all other tasks to.
43 Within LCPD we currently say that a story that can be completed in a day
44 or less has a value of 1 story point.  This does not imply that story points
45 map to days.  Rather think of a story point as something between 4-8 hours of
46 work.  So 3 story points is about 3 times more difficult that a single story
47 point item.
49 \paragraph{}
50 Another reason to use story points instead of other metrics such as
51 hours or ideal hours is that in these cases the metric itself starts to
52 distract from the effort estimate.  For example if you were asked to dig
53 the hole about and tell roughly how many hours it would take, you might
54 start thinking about non-related details like whether you would need to
55 take time to go buy a shovel, will you need a lunch break, what about your
56 doctor's appointment on Tuesday?  Hours touches people at a "real" level
57 and instead of keeping them focused on the relative size and complexity of
58 the story they start worrying about things that can distract them.
60 \paragraph{}
61 Further, hours leads to a desire to be precise.  If you say a task is going
62 to take 60 hours you will likely feel the need to make sure you can get the
63 task done in exactly 60 hours.  But for a tasks that takes 60 hours, is 64
64 really that much more?  Is 56 that much less?  So why not give it a set of
65 story points that say it is a task that is \textit{about} 60 hours and
66 not worry about the small details.
68 \paragraph{}
69 There are other ways to estimate such as using shirt sizes like small, medium,
70 large, x-large.  as you will see in section \ref{sec:estimating-tool} we will
71 use a tool that uses a rough fibonacci sequence to allow concurrent estimation
72 for teams in a distributed environment.
74 \section{Estimating Tool}
75 \label{sec:estimating-tool}
77 \paragraph{}
78 One of the important things about estimating backlog items is the idea of
79 the simultaneous reveal of the estimation.  This is important because it
80 allows everyone to put out their estimation without being influenced by
81 the person(s) before them.  This is easy to do when everyone is in one
82 location but how do you do then on distributed teams where people may
83 be interacting with each other over the phone?
85 \paragraph{}
86 Luckily for us the fine people of "Mountain Goat Software" have an online
87 version of planning poker which allows the entire team to participate in
88 the estimation effort while still having the simultaneous reveal capability
89 that keeps people from having their opinions jaded by others.  This tool
90 can be found at \url{} and you can create
91 a free account.
93 \paragraph{}
94 This tool allows uploading stories, discussing them, having each team member
95 give an estimate of the level of effort with a simultaneous reveal.  If the
96 estimates do not match then the team can further discuss the item and re-vote
97 until a consensus is reached.  At the end of the planning session the items
98 and their estimates can be exported.
100 \section{Estimated Task Is Too Large To Fit In One Sprint}
101 \label{sec:estimated-task-is-too-large}
103 \paragraph{}
104 Sometime during estimation the story may be too large to fit into a single
105 sprint.  This may be because of some ambiguity about what the story entails,
106 or just that it simple is too much based on the team's velocity.  If this is
107 the case you should promote the story into an epic and then start working to
108 break this epic up into smaller stories that can be estimated to fit within
109 a single sprint.  For more details see chapter \ref{chap:work-breakdown}.