the-sprint: fix typos and enhance readability
authorChase Maupin <chase.maupin@ti.com>
Fri, 12 Apr 2013 15:02:01 +0000 (10:02 -0500)
committerFelipe Balbi <balbi@ti.com>
Fri, 12 Apr 2013 15:13:31 +0000 (18:13 +0300)
* Some changes look larger because of enforcing 80 character
  limits.

Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
the-sprint.tex

index a8cb2a23b5323dc1142fa0cba9694cd3a6c0777a..4654cb1d3717570f6a19e302124f6e5062d9ea31 100644 (file)
@@ -33,16 +33,16 @@ chapter \ref{chap:definition-of-done}.
 \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.
+Linux Core Product Development team will use a sprint duration of 2 weeks with
+no exceptions. This is the most common 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
+       \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}
 
@@ -53,18 +53,18 @@ 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.
+Item \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
+opportunity 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.
+performed in a set of continuous feedback loops.
 
 \begin{figure}[ht]
        \centering
@@ -100,8 +100,8 @@ 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
+to it? The answer to that question lies in methodical and (hopefully)
+automated 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.