diff options
author | Chase Maupin | 2013-04-12 10:02:01 -0500 |
---|---|---|
committer | Felipe Balbi | 2013-04-12 10:13:31 -0500 |
commit | e6e04a03fe26d4fcbb32ffe3ef8cc2ba7f4596a3 (patch) | |
tree | c020fe89afd7a81fa65a57fdedbdca4f190cef9b | |
parent | ab4602aa0998494d408eae063bfc74cade055067 (diff) | |
download | ti-agile-manual-e6e04a03fe26d4fcbb32ffe3ef8cc2ba7f4596a3.tar.gz ti-agile-manual-e6e04a03fe26d4fcbb32ffe3ef8cc2ba7f4596a3.tar.xz ti-agile-manual-e6e04a03fe26d4fcbb32ffe3ef8cc2ba7f4596a3.zip |
the-sprint: fix typos and enhance readability
* 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>
-rw-r--r-- | the-sprint.tex | 26 |
1 files changed, 13 insertions, 13 deletions
diff --git a/the-sprint.tex b/the-sprint.tex index a8cb2a2..4654cb1 100644 --- a/the-sprint.tex +++ b/the-sprint.tex | |||
@@ -33,16 +33,16 @@ chapter \ref{chap:definition-of-done}. | |||
33 | \label{sec:sprint-duration} | 33 | \label{sec:sprint-duration} |
34 | 34 | ||
35 | \paragraph{} | 35 | \paragraph{} |
36 | Linux Core Product Development team will use sprint of 2 weeks with no | 36 | Linux Core Product Development team will use a sprint duration of 2 weeks with |
37 | exceptions. This is the most usual choice for beginners in Agile practices and, | 37 | no exceptions. This is the most common choice for beginners in Agile practices |
38 | in particular, Scrum. | 38 | and, in particular, Scrum. |
39 | 39 | ||
40 | \paragraph{} | 40 | \paragraph{} |
41 | A 2-week sprint brings two clear benefits: | 41 | A 2-week sprint brings two clear benefits: |
42 | 42 | ||
43 | \begin{enumerate} | 43 | \begin{enumerate} |
44 | \item it's a short amount of time.\label{item:short-amount-of-time} | 44 | \item It's a short amount of time.\label{item:short-amount-of-time} |
45 | \item it's not as short as to cause too few story points to be taken | 45 | \item It's not as short as to cause too few story points to be taken |
46 | in a given sprint.\label{item:not-too-short} | 46 | in a given sprint.\label{item:not-too-short} |
47 | \end{enumerate} | 47 | \end{enumerate} |
48 | 48 | ||
@@ -53,18 +53,18 @@ considerable amount of work -- only 2 weeks -- and we can easily fix that on | |||
53 | the next sprint. | 53 | the next sprint. |
54 | 54 | ||
55 | \paragraph{} | 55 | \paragraph{} |
56 | \ref{item:not-too-short}, on the other hand, makes it easier to see progress. | 56 | Item \ref{item:not-too-short}, on the other hand, makes it easier to see |
57 | Even though we are focussing on time-boxing our sprints and making them small | 57 | progress. Even though we are focussing on time-boxing our sprints and making |
58 | enough as to decrease risks, we can still have a considerable amount of new | 58 | them small enough as to decrease risks, we can still have a considerable amount |
59 | features finished by the end of the sprint which, in turn, gives us the | 59 | of new features finished by the end of the sprint which, in turn, gives us the |
60 | oportunity of coming up with good demos. | 60 | opportunity of coming up with good demos. |
61 | 61 | ||
62 | \section{Scrum Process} | 62 | \section{Scrum Process} |
63 | \label{sec:scrum-process} | 63 | \label{sec:scrum-process} |
64 | 64 | ||
65 | \paragraph{} | 65 | \paragraph{} |
66 | Figure \ref{fig:scrum-process} shows Scrum's process. Note that development is | 66 | Figure \ref{fig:scrum-process} shows Scrum's process. Note that development is |
67 | carried away as a loop. | 67 | performed in a set of continuous feedback loops. |
68 | 68 | ||
69 | \begin{figure}[ht] | 69 | \begin{figure}[ht] |
70 | \centering | 70 | \centering |
@@ -100,8 +100,8 @@ working software inside of Scrum; or at least that will always be the target. | |||
100 | 100 | ||
101 | \paragraph{} | 101 | \paragraph{} |
102 | But how can anyone be sure that software is working before customer has access | 102 | But how can anyone be sure that software is working before customer has access |
103 | to it ? The answer to that question lies in methodical and (hopefully) | 103 | to it? The answer to that question lies in methodical and (hopefully) |
104 | automatic testing. Each task in Scrum should be tied to a companion testcase | 104 | automated testing. Each task in Scrum should be tied to a companion testcase |
105 | proving that software fails before implementing that task and passes after the | 105 | proving that software fails before implementing that task and passes after the |
106 | fact. | 106 | fact. |
107 | 107 | ||