%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                                       %%
%% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
%%                                                                       %%
%% Author: Felipe Balbi <balbi@ti.com>                                   %%
%% Author: Luciano Coelho <coelho@ti.com>                                %%
%%                                                                       %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Work Breakdown}
\label{chap:work-breakdown}

\paragraph{}
Planning large features is a very difficult process, due to the lack
of visibility of details at an early phase.  As the work progresses
and the feature is studied in more detail, issues that were not taken
into account during the initial planning phase are very likely to show
up.  This is one of the main causes of missed deadlines when the
waterfall process is used.

\paragraph{}
To address this problem, \textit{Scrum} defines a concept called
\textit{Backlog Grooming}.  The main idea is that at first, the
planning of a feature is very rough and imprecise, but as work
progresses it becomes more and more fine-grained and accurate.  This
gives the entire team more confidence on the estimates as time passes
towards completion of the feature.  This is accomplished by studying
the product backlog regularly and trying to break things down into
smaller pieces, in a recursive process called \textit{Product Backlog
  Grooming}.  Additionally, once the sprint backlog is defined, it is
hammered down into bite-sized steps, during the \textit{Sprint Backlog
  Grooming}.

\paragraph{}
There are two different types of product backlog items:
\textit{epics}, which are large items whose details are not well-known
and may spread across several sprints; and \textit{stories}, which are
small items that describe entire features with a certain level of
detail and can fit inside a single sprint.  Furthermore, we have
\textit{tasks}, sprint backlog items that represent the detailed steps
needed to complete a story.

\paragraph{}
The following sections describe all these concepts in detail.

\section{Epics}
\label{sec:epics}

\paragraph{}
The largest type of backlog item in \textit{Scrum} is the
\textit{Epic}.  The team only has a general idea of what needs to be
done, because there are too many unknowns and the item is too large
for any kind of serious commitment.  It is used only in the product
backlog.

\paragraph{}
As an example, an epic may be described as ``Implement an error
management system''.  There are many questions to this item which are
not answered yet, eg. ``what does an error consist of?'', ``what
operations are needed?'', ``what are the user roles?'' etc.

\paragraph{}
An \textit{Epic} needs to go through several iterations of grooming,
where these questions are answered.  At each iteration, one or more
stories are spun out of it.  This happens recursively until the epic
itself becomes small and self-contained enough to be downgraded to a
story.

\section{Stories}
\label{sec:stories}

\paragraph{}
The grooming process generates intermediate backlog items called
\textit{Stories}.  A story is an Independent, Negotiable, Valuable,
Estimable, Sized appropriately and Testable (INVEST) requirement that
is usually represented as an \textit{action} done by an \textit{actor}
to achieve a \textit{goal}.

\paragraph{}
After each iteration of grooming, an epic will spawn one or more
\textit{stories}.  The level of understanding increases and rough
estimates can be made.

\paragraph{}
In our example, during the backlog grooming meeting, the team will
break the ``Implement an error management system'' into several
stories: ``As an error manager, I can create databases so that each
project has its own database''; ``as an error reporter, I can enter
error items into the system so they can be analysed and acted upon'';
``as a developer, I can enter information into an error item so that
progress can be followed''; and so on.

\paragraph{}
Some of these new stories are not fine-grained enough and need to go
through more iterations of study so they can be broken down into even
smaller pieces.  For instance, ``as a developer, I can enter
information into an error item so that progress can be followed''
could be split into: ``as a developer, I can add comments to an error
item''; ``as a developer I can mark the error as fixed''; ``as a
developer I can ask that an error item be clarified'' and so forth.

\paragraph{}
A user story has a high-level estimate assigned by the team during the
backlog grooming.  This estimates are relative values and do not
represent real time.  Each team member votes for an estimate and the
votes are discussed until the team reaches a consensus.  For more
information see chapter \ref{chap:estimating}.

\paragraph{}
Each user story contains \textit{Acceptance Criteria}, which
explicitly define what needs to work and pass testing so that the
story can be considered done.  It can be considered a
story-specific addition to the definition of done.  See section
\ref{sec:diff-acceptance-criteria} for more details.

\section{Tasks}
\label{sec:tasks}


\section{Product Backlog Grooming}
\label{sec:product-backlog-grooming}


\section{Sprint Backlog Grooming}
\label{sec:sprint-backlog-grooming}
