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

\chapter{The Sprint}
\label{chap:the-sprint}

\paragraph{}
The \textit{basic unit of development in Scrum}\cite{wikipediascrum} whose
duration is pre-defined. All sprints have the same duration, usually between
one week and one month.

\paragraph{}
In section \ref{sec:sprint-duration} we shall discuss about Sprint Duration and
what is Linux Core Product Development's accepted duration. In the following
section \ref{sec:scrum-process} we shall expose Scrum's development process and
discuss how to handle an iterative development model while developing Linux
Kernel code. Lastly, on section \ref{sec:sprint-burndown-charts} we will expose
the idea of Sprint Burndown Charts; what they are and how to use them.

\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:estimating} and finally come up with our definition of done in
chapter \ref{chap:definition-of-done}.

\section{Sprint Duration}
\label{sec:sprint-duration}

\paragraph{}
Linux Core Product Development team will use sprint of 2 weeks with no
exceptions. This is the most usual choice for beginners in Agile practices and,
in particular, Scrum.

\paragraph{}
A 2-week sprint brings two clear benefits:

\begin{enumerate}
	\item it's a short amount of time.\label{item:short-amount-of-time}
	\item it's not as short as to cause too few story points to be taken
		in a given sprint.\label{item:not-too-short}
\end{enumerate}

\paragraph{}
Due to item \ref{item:short-amount-of-time}, risk management becomes easy. If
it turns out a particular sprint isn't successful, we're not loosing a
considerable amount of work --  only 2 weeks -- and we can easily fix that on
the next sprint.

\paragraph{}
\ref{item:not-too-short}, on the other hand, makes it easier to see progress.
Even though we are focussing on time-boxing our sprints and making them small
enough as to decrease risks, we can still have a considerable amount of new
features finished by the end of the sprint which, in turn, gives us the
oportunity of coming up with good demos.

\section{Scrum Process}
\label{sec:scrum-process}

\paragraph{}
Figure \ref{fig:scrum-process} shows Scrum's process. Note that development is
carried away as a loop.

\begin{figure}[ht]
	\centering
	\includegraphics[width=0.8\textwidth]{images/scrum-process.png}
	\caption{Scrum Process}
	\label{fig:scrum-process}
\end{figure}

\paragraph{}
There a few things to note here. First, when product backlog feeds sprint
backlogs, they become small, self-contained, estimated tasks which, can be
finished in the course of one day. This means that on each and every daily
scrum meeting, \textbf{ideally}, everybody should have an update. Clearly this
won't always be the case as problems arise.

\paragraph{}
Second, there are two loops that are carried over during a Scrum development
effort. The bigger loop is the sprint loop which, in our case, as we shall see,
will take 2 weeks. The smaller, and perhaps more important, loop is the daily
scrum.

\paragraph{}
The daily scrum -- that is, the daily 15 minutes meetings --, is of utmost
importance for the success of any Scrum development team. It gives developers
and managers visibility which hasn't been possible before. Such visibility
leads to roadblocks being solved much quicker which, in turn, leads to
development flowing smoothly towards the end product.

\paragraph{}
Third, after each Sprint there should be a \textbf{working} increment of the
software. The bold face in \textit{working} was purposeful. We can only deliver
working software inside of Scrum; or at least that will always be the target.

\paragraph{}
But how can anyone be sure that software is working before customer has access
to it ? The answer to that question lies in methodical and (hopefully)
automatic testing. Each task in Scrum should be tied to a companion testcase
proving that software fails before implementing that task and passes after the
fact.

\section{Sprint Burndown Charts}
\label{sec:sprint-burndown-charts}

\paragraph{}
The burndown chart is a simple way to visualize how current sprint is
developing. It shows, at any given time, how many hours and days are left for
this sprint.

\paragraph{}
By looking at older sprints, we can also extrapolate the data to generate
valuable statistics about the team. The \textit{Team Velocity} is one of such
statistics and it tells us how many Story Points (or engineering hours) are
completed per-sprint. That information allows ScrumMasters to estimate when the
entire project will be complete.

\paragraph{}
Figure \ref{fig:example-burndown-chart} below shows an example Sprint Burndown
Chart.

\begin{figure}[ht]
	\centering
	\pgfplotsset{width=12cm}
	\pgfplotsset{grid style={dashed,lightgray}}
	\begin{tikzpicture}
		\begin{axis}[xlabel=Days,ylabel=Effort (hours),grid=both]
			\addplot coordinates {
				(1, 60)
				(2, 51)
				(3, 47)
				(4, 40)
				(5, 35)
				(6, 22)
				(7, 13)
				(8, 8)
				(9, 3)
				(10, 0)
			};
		\end{axis}
	\end{tikzpicture}
	\caption{Example Sprint Burndown Chart}
	\label{fig:example-burndown-chart}
\end{figure}

\paragraph{}
It's easy to see how we can extrapolate team velocity after we have more than
one Sprint Burndown Chart available.
