the-sprint.tex

   1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   2 %%                                                                       %%
   3 %% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
   4 %%                                                                       %%
   5 %% Author: Felipe Balbi <balbi@ti.com>                                   %%
   6 %%                                                                       %%
   7 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   8
   9 \chapter{The Sprint}
  10 \label{chap:the-sprint}
  11
  12 \paragraph{}
  13 The \textit{basic unit of development in Scrum}\cite{wikipediascrum} whose
  14 duration is pre-defined. All sprints have the same duration, usually between
  15 one week and one month.
  16
  17 \paragraph{}
  18 In section \ref{sec:sprint-duration} we shall discuss about Sprint Duration and
  19 what is Linux Core Product Development's accepted duration. In the following
  20 section \ref{sec:sprint-process} we shall expose Scrum's development process and
  21 discuss how to handle an iterative development model while developing Linux
  22 Kernel code.
  23
  24 \paragraph{}
  25 By the end of this chapter, we should have enough grounds to discuss about how
  26 to successfully break backlog entries into bite-sized pieces in chapter
  27 \ref{chap:breaking-tasks-up}, how to come up with proper estimations in chapter
  28 \ref{chap:estimating} and finally come up with our definition of done in
  29 chapter \ref{chap:definition-of-done}.
  30
  31 \section{Sprint Duration}
  32 \label{sec:sprint-duration}
  33
  34 \paragraph{}
  35 Linux Core Product Development team will use a sprint duration of 2 weeks with
  36 no exceptions. This is the most common choice for beginners in Agile practices
  37 and, in particular, Scrum.
  38
  39 \paragraph{}
  40 A 2-week sprint brings two clear benefits:
  41
  42 \begin{enumerate}
  43         \item It's a short amount of time.\label{item:short-amount-of-time}
  44         \item It's not as short as to cause too few story points to be taken
  45                 in a given sprint.\label{item:not-too-short}
  46 \end{enumerate}
  47
  48 \paragraph{}
  49 Due to item \ref{item:short-amount-of-time}, risk management becomes easy. If
  50 it turns out a particular sprint isn't successful, we're not loosing a
  51 considerable amount of work --  only 2 weeks -- and we can easily fix that on
  52 the next sprint.  A 2 week duration also allows a reasonable response time
  53 to changing priorities in the backlog such as customer issues.
  54
  55 \paragraph{}
  56 Item \ref{item:not-too-short}, on the other hand, makes it easier to see
  57 progress. Even though we are focussing on time-boxing our sprints and making
  58 them small enough as to decrease risks, we can still have a considerable amount
  59 of new features finished by the end of the sprint which, in turn, gives us the
  60 opportunity of coming up with good demos.
  61
  62 \section{Sprint Process}
  63 \label{sec:sprint-process}
  64
  65 \paragraph{}
  66 Figure \ref{fig:scrum-process} shows Scrum's overall process. Note that
  67 development is performed in a set of continuous feedback loops.
  68
  69 \begin{figure}[ht]
  70         \centering
  71         \includegraphics[width=0.8\textwidth]{images/scrum-process.png}
  72         \caption{Scrum Process}
  73         \label{fig:scrum-process}
  74 \end{figure}
  75
  76 \paragraph{}
  77 There a few things to note here. First, when product backlog feeds sprint
  78 backlogs, they become small, self-contained, estimated tasks which, can be
  79 finished in the course of one day. This means that on each and every daily
  80 scrum meeting, \textbf{ideally}, everybody should have an update. Clearly this
  81 won't always be the case as problems arise.
  82
  83 \paragraph{}
  84 Second, there are two loops that are carried over during a Sprint development
  85 effort. The bigger loop is the sprint loop which, in our case, as we shall see,
  86 will take 2 weeks. The smaller, and perhaps more important, loop is the daily
  87 scrum.
  88
  89 \paragraph{}
  90 The daily scrum -- that is, the daily 15 minutes meetings --, is of utmost
  91 importance for the success of any Scrum development team. It gives developers
  92 and managers visibility which hasn't been possible before. Such visibility
  93 leads to roadblocks being solved much quicker which, in turn, leads to
  94 development flowing smoothly towards the end product.  This meeting is
  95 discussed in more detail in chapter \ref{chap:meetings}.
  96
  97 \paragraph{}
  98 Third, after each Sprint there should be a \textbf{working} increment of the
  99 software. The bold face in \textit{working} was purposeful. We can only deliver
 100 working software inside of Scrum; or at least that will always be the target.
 101
 102 \paragraph{}
 103 But how can anyone be sure that software is working before customer has access
 104 to it? The answer to that question lies in methodical and (hopefully)
 105 automated testing. Each task in Scrum should be tied to a companion testcase
 106 proving that software fails before implementing that task and passes after the
 107 fact.
 108
 109 \paragraph{}
 110 The test case and code/scripts and documentation used to run that test case
 111 are artifacts of the sprint and should be delivered to the system test team
 112 for integration into the automated test system.  This is refere to in chapter
 113 \ref{chap:definition-of-done} as part of the definition of done.