grooming: rename chapter and add initial text
authorLuciano Coelho <coelho@ti.com>
Thu, 16 May 2013 09:09:31 +0000 (12:09 +0300)
committerFelipe Balbi <balbi@ti.com>
Tue, 21 May 2013 15:44:21 +0000 (18:44 +0300)
Rename the "Breaking tasks into bite size pieces" chapter into "Work
Breakdown", write an introduction and the descriptions of Epics and
Stories.

Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
breaking-tasks-up.tex [deleted file]
estimating.tex
introduction.tex
the-sprint.tex
ti-agile-methodology-manual.tex
work-breakdown.tex [new file with mode: 0644]

diff --git a/breaking-tasks-up.tex b/breaking-tasks-up.tex
deleted file mode 100644 (file)
index 778c6a9..0000000
+++ /dev/null
@@ -1,19 +0,0 @@
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%                                                                       %%
-%% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
-%%                                                                       %%
-%% Author: Felipe Balbi <balbi@ti.com>                                   %%
-%%                                                                       %%
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\chapter{Breaking Tasks into Bite-sized Pieces}
-\label{chap:breaking-tasks-up}
-
-\section{Example Scenario}
-\label{sec:example-scenario}
-
-\section{Breaking Is Recursive}
-\label{sec:breaking-is-recursive}
-
-\section{Finishing It All Up}
-\label{sec:finishing-it-all-up}
index ca3f0a7a19287766dea96edfa57c92e47454b81e..27ea8d66df89bd5c814afddbdf3237ec4b2bf6e4 100644 (file)
@@ -101,4 +101,4 @@ 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}
+a single sprint.  For more details see chapter \ref{chap:work-breakdown}.
index 3c059038d11fa85553646bb93d73726aad2a33ad..4fab48ed95372dbcbcd23b0ab105e3184e6caa55 100644 (file)
@@ -61,10 +61,11 @@ A thorough discussion about the Sprint will be carried throughout chapter
 more.
 
 \paragraph{}
-A discussion about how to break tasks into small pieces will be exposed in
-chapter \ref{chap:breaking-tasks-up}. We will learn tricks which will help us
-understand how to break e.g. \textit{Development of QSPI driver} into smaller,
-bite-sized pieces which can done in the course of one sprint.
+A discussion about how to break tasks into small pieces will be
+exposed in chapter \ref{chap:work-breakdown}.  We will learn tricks
+which will help us understand how to break work items
+(eg. \textit{Implement an error management system} into smaller,
+bite-sized pieces that can be done in the course of one sprint.
 
 \paragraph{}
 After being able to break tasks into small pieces, we need to come up with
index 86efb27ffc2cb2791f02bf6be2eeba442407f5e6..3636d76e2c68d2b3e582704245970ee761165a86 100644 (file)
@@ -24,7 +24,7 @@ Kernel code.
 \paragraph{}
 By the end of this chapter, we should have enough grounds to discuss about how
 to successfully break backlog entries into bite-sized pieces in chapter
-\ref{chap:breaking-tasks-up}, how to come up with proper estimations in chapter
+\ref{chap:work-breakdown}, how to come up with proper estimations in chapter
 \ref{chap:estimating} and finally come up with our definition of done in
 chapter \ref{chap:definition-of-done}.
 
index cfdabac78e4b61403191d53837114ec5159b63b4..238512945e9395cc55e94d62e9fae1a14ebcf50e 100644 (file)
@@ -69,7 +69,7 @@
 \input{roles.tex}
 \input{meetings.tex}
 \input{the-sprint.tex}
-\input{breaking-tasks-up.tex}
+\input{work-breakdown.tex}
 \input{estimating.tex}
 \input{definition-of-done.tex}
 
diff --git a/work-breakdown.tex b/work-breakdown.tex
new file mode 100644 (file)
index 0000000..61f4abb
--- /dev/null
@@ -0,0 +1,125 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%                                                                       %%
+%% 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}