life-cycle-of-story: Add creation of upstream stories
[ti-agile-manual/ti-agile-manual.git] / work-breakdown.tex
1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2 %%                                                                       %%
3 %% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
4 %%                                                                       %%
5 %% Author: Felipe Balbi <balbi@ti.com>                                   %%
6 %% Author: Luciano Coelho <coelho@ti.com>                                %%
7 %%                                                                       %%
8 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
10 \chapter{Work Breakdown}
11 \label{chap:work-breakdown}
13 \paragraph{}
14 Planning large features is a very difficult process, due to the lack
15 of visibility of details at an early phase.  As the work progresses
16 and the feature is studied in more detail, issues that were not taken
17 into account during the initial planning phase are very likely to show
18 up.  This is one of the main causes of missed deadlines when the
19 waterfall process is used.
21 \paragraph{}
22 To address this problem, \textit{Scrum} defines a concept called
23 \textit{Backlog Grooming}.  The main idea is that at first, the
24 planning of a feature is very rough and imprecise, but as work
25 progresses it becomes more and more fine-grained and accurate.  This
26 gives the entire team more confidence on the estimates as time passes
27 towards completion of the feature.  This is accomplished by studying
28 the product backlog regularly and trying to break things down into
29 smaller pieces, in a recursive process called \textit{Product Backlog
30   Grooming}.  Additionally, once the sprint backlog is defined, it is
31 hammered down into bite-sized steps, during the \textit{Sprint Backlog
32   Grooming}.
34 \paragraph{}
35 There are two different types of product backlog items:
36 \textit{epics}, which are large items whose details are not well-known
37 and may spread across several sprints; and \textit{stories}, which are
38 small items that describe entire features with a certain level of
39 detail and can fit inside a single sprint.  Furthermore, we have
40 \textit{tasks}, sprint backlog items that represent the detailed steps
41 needed to complete a story.
43 \paragraph{}
44 The following sections describe all these concepts in detail.
46 \section{Epics}
47 \label{sec:epics}
49 \paragraph{}
50 The largest type of backlog item in \textit{Scrum} is the
51 \textit{Epic}.  The team only has a general idea of what needs to be
52 done, because there are too many unknowns and the item is too large
53 for any kind of serious commitment.  It is used only in the product
54 backlog.
56 \paragraph{}
57 As an example, an epic may be described as ``Implement an error
58 management system''.  There are many questions to this item which are
59 not answered yet, eg. ``what does an error consist of?'', ``what
60 operations are needed?'', ``what are the user roles?'' etc.
62 \paragraph{}
63 An \textit{Epic} needs to go through several iterations of grooming,
64 where these questions are answered.  At each iteration, one or more
65 stories are spun out of it.  This happens recursively until the epic
66 itself becomes small and self-contained enough to be downgraded to a
67 story.
69 \section{Stories}
70 \label{sec:stories}
72 \paragraph{}
73 The grooming process generates intermediate backlog items called
74 \textit{Stories}.  A story is an Independent, Negotiable, Valuable,
75 Estimable, Sized appropriately and Testable (INVEST) requirement that
76 is usually represented as an \textit{action} done by an \textit{actor}
77 to achieve a \textit{goal}.
79 \paragraph{}
80 After each iteration of grooming, an epic will spawn one or more
81 \textit{stories}.  The level of understanding increases and rough
82 estimates can be made.
84 \paragraph{}
85 In our example, during the backlog grooming meeting, the team will
86 break the ``Implement an error management system'' into several
87 stories: ``As an error manager, I can create databases so that each
88 project has its own database''; ``as an error reporter, I can enter
89 error items into the system so they can be analysed and acted upon'';
90 ``as a developer, I can enter information into an error item so that
91 progress can be followed''; and so on.
93 \paragraph{}
94 Some of these new stories are not fine-grained enough and need to go
95 through more iterations of study so they can be broken down into even
96 smaller pieces.  For instance, ``as a developer, I can enter
97 information into an error item so that progress can be followed''
98 could be split into: ``as a developer, I can add comments to an error
99 item''; ``as a developer I can mark the error as fixed''; ``as a
100 developer I can ask that an error item be clarified'' and so forth.
102 \paragraph{}
103 A user story has a high-level estimate assigned by the team during the
104 backlog grooming.  This estimates are relative values and do not
105 represent real time.  Each team member votes for an estimate and the
106 votes are discussed until the team reaches a consensus.  For more
107 information see chapter \ref{chap:estimating}.
109 \paragraph{}
110 Each user story contains \textit{Acceptance Criteria}, which
111 explicitly define what needs to work and pass testing so that the
112 story can be considered done.  It can be considered a
113 story-specific addition to the definition of done.  See section
114 \ref{sec:diff-acceptance-criteria} for more details.
116 \section{Tasks}
117 \label{sec:tasks}
120 \section{Product Backlog Grooming}
121 \label{sec:product-backlog-grooming}
124 \section{Sprint Backlog Grooming}
125 \label{sec:sprint-backlog-grooming}