From 8f4ce1ee0a2ca9c7a748684eccb8602aea7cc0ea Mon Sep 17 00:00:00 2001 From: Luciano Coelho Date: Thu, 16 May 2013 12:09:31 +0300 Subject: [PATCH] grooming: rename chapter and add initial text 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 Signed-off-by: Felipe Balbi --- breaking-tasks-up.tex | 19 ----- estimating.tex | 2 +- introduction.tex | 9 ++- the-sprint.tex | 2 +- ti-agile-methodology-manual.tex | 2 +- work-breakdown.tex | 125 ++++++++++++++++++++++++++++++++ 6 files changed, 133 insertions(+), 26 deletions(-) delete mode 100644 breaking-tasks-up.tex create mode 100644 work-breakdown.tex diff --git a/breaking-tasks-up.tex b/breaking-tasks-up.tex deleted file mode 100644 index 778c6a9..0000000 --- a/breaking-tasks-up.tex +++ /dev/null @@ -1,19 +0,0 @@ -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -%% %% -%% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %% -%% %% -%% Author: Felipe Balbi %% -%% %% -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -\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} diff --git a/estimating.tex b/estimating.tex index ca3f0a7..27ea8d6 100644 --- a/estimating.tex +++ b/estimating.tex @@ -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}. diff --git a/introduction.tex b/introduction.tex index 3c05903..4fab48e 100644 --- a/introduction.tex +++ b/introduction.tex @@ -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 diff --git a/the-sprint.tex b/the-sprint.tex index 86efb27..3636d76 100644 --- a/the-sprint.tex +++ b/the-sprint.tex @@ -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}. diff --git a/ti-agile-methodology-manual.tex b/ti-agile-methodology-manual.tex index cfdabac..2385129 100644 --- a/ti-agile-methodology-manual.tex +++ b/ti-agile-methodology-manual.tex @@ -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 index 0000000..61f4abb --- /dev/null +++ b/work-breakdown.tex @@ -0,0 +1,125 @@ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%% %% +%% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %% +%% %% +%% Author: Felipe Balbi %% +%% Author: Luciano Coelho %% +%% %% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\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} -- 2.39.2