099fb633c45287ebf088f6a6300a38f9ea4e0e98
1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2 %% %%
3 %% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
4 %% %%
5 %% Author: Chase Maupin <chase.maupin@ti.com> %%
6 %% %%
7 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
9 \chapter{Life Cycle of a Story}
10 \label{chap:life-cycle-of-story}
12 \paragraph{}
13 This chapter focuses on how a Story (or PBI) progresses through a sprint
14 and the VersionOne tool used by the LCPD team. The goal of this chapter
15 is to help user's know how they will move their stories from creation to
16 Done within the tool.
18 \begin{enumerate}
19 \item The initial story is created within VersionOne. In VersionOne
20 stories are called \textbf{Backlog Items}. These backlog items,
21 or \textbf{PBIs}, can be created in multiple locations in the tool
22 and can be added by most project members at any time in the project
23 life cycle. For example:
24 \begin{itemize}
25 \item A \textbf{Product Owner} may add PBIs to the list as
26 they receive them from the \textbf{Stake Holders}
27 \item A \textbf{Scrum Team Member} may add a PBI to the list
28 during their development to track additional work found
29 that is not part of the current story or to track future
30 work.
31 \item A \textbf{Scrum Team Member} may add a PBI to the list
32 as part of the backlog refinement or sprint planning if
33 an existing item is found to be too large and should be
34 split.
35 \end{itemize}
36 In all of the above cases this is usually done by clicking the
37 \textit{Add Backlog Item Inline or Add Backlog Item} button.
38 \item During the creation of a PBI the following information should be
39 captured:
40 \begin{itemize}
41 \item[\textbf{Title:}] This is the short description of the PBI
42 which will be seen in the backlog view.
43 \item[\textbf{Team:}] At PBI creation this should be the functional
44 team that the PBI belongs to (e.g. Connectivity or System
45 Integration)
46 \item[\textbf{Feature Group:}] The device that the PBI applies to.
47 For generic PBIs this should be \textit{ALL}.
48 \item[\textbf{Epic:}] The Epic this PBI belongs to if any. New
49 epics should not be created, but instead PBI should be added
50 within the existing epics. If you feel you need a new Epic
51 please work with your scrum master to add it. For generic
52 PBIs there are generic top-level epics, while for device
53 specific PBIs there are device specific epics.
54 \item[\textbf{Description:}] This should contain the details about
55 the backlog item such as current status, any work already
56 available, and \textbf{most importantly Acceptance Criteria}.
57 \item[\textbf{Estimate:}] This should only be added if an item is
58 being created during a \textbf{Sprint Planning or Backlog
59 Refinement} meeting. If not this should be left blank so it
60 can be estimated by the team later.
61 \item[\textbf{Owners:}] This should only be added when a backlog
62 item is being added by a specific developer and they are
63 planning this item for themselves.
64 \item[\textbf{Priority:}] This should only be set by the
65 \textit{Product Owner} if they are creating the item. All
66 other times this should be left blank for the Product Owner
67 to assign.
68 \end{itemize}
69 \item Now that the PBI has been created it likely needs prioritization.
70 This is the role of the \textbf{Product Owner} and they should be
71 reviewing the backlog periodically to prioritize items without a
72 priority set.
73 \item With a prioritized backlog, and the assumption that our new PBI is
74 the highest priority, we can now estimate the size of the backlog
75 item if it has not already been done. Many times this will be
76 done as part of the functional team meeting described in section
77 \ref{sec:functionalteammeeting}, but if not will be done during
78 the first part of the sprint planning.
79 \item We now have enough information to start planning our PBI for the
80 sprint. During sprint planning the sprint team will check the
81 estimate. If they believe the item is too large then they should
82 break it down into smaller PBIs and repeat the above process for
83 each. Once they believe the PBI can be completed within the
84 current sprint they should:
85 \begin{itemize}
86 \item Change the \textbf{Team} value to their scrum team. This
87 will be important to help filter the task board view for
88 only their items as we will discuss later.
89 \item Add it to the sprint backlog. This can be done by editing
90 the item and assigning a value in the \textbf{Sprint} field
91 or dragging the PBI from the release backlog to the desired
92 sprint withing the \textbf{Sprint Planning} view.
93 \end{itemize}
94 \item With the PBI added to the sprint it is now time to break that item
95 down into tasks as part of the second sprint planning meeting.
96 There are many ways this can be done but the most common is to use
97 the \textbf{Taskboard} view in the \textbf{Sprint Tracking} tab to
98 see the current PBIs within the sprint. You can filter the PBIs to
99 only those signed up to by your team using the \textit{Team}
100 drop-down. To plan an PBI you can click the small arrow in the
101 upper-right corner and selecting either:
102 \begin{itemize}
103 \item[\textbf{Add Task:}] to add a new task for the PBI. You should
104 fill in the \textit{Detail Estimate} field with the number of
105 hours the task should take. Keep in mind that a task should
106 no more than 1 day of effort.
107 \item[\textbf{Add Test:}] to add a new set test item which will be
108 displayed in the \textbf{Testboard} view. These tests will
109 allow you to track progress for the completion of the PBI and
110 also give the system test team a view of where they can assist
111 other team. The dialog for the test task includes fields
112 to contain setup, steps, expected results, etc.
113 \end{itemize}
114 You should break down your PBIs as much as possible during the sprint
115 planning meeting, but new tasks can be added over time.
116 \item For each task you should give an estimate of the number of
117 \textbf{hours} that task will require. This is to allow you to
118 track the ToDo progress during your sprint. Tasks are estimated
119 in hours vs story points because they should be able to be done
120 in a single day.
121 \item You are now ready to start the sprint and begin working on your
122 tasks. The first thing you should do is decide which task you want
123 to start working on and using the drop down from the arrow in the
124 upper-right select \textbf{Sign Me Up}. You should then move that
125 task to \textbf{In Progress} so that other know it is already
126 being worked. You can do this by dragging and dropping the task
127 to the In Progress Column. You can do this for as many tasks as
128 you will be working on that day.
129 \item At the end of each day (or at least before your daily scrum meeting)
130 you should make sure to update the \textbf{taskboard}. This
131 involves:
132 \begin{itemize}
133 \item Moving the tasks into the appropriate column of the
134 taskboard.
135 \item Updating the hours worked and ToDo on a task. This can
136 be done by selecting the ``Track'' option for the task and
137 putting the hours worked towards that task in the
138 \textbf{effort} field and updating the \textbf{ToDo} field
139 to subtract those hours.
140 \end{itemize}
141 \item At the end of each day (or at least before your daily scrum meeting)
142 you should make sure to update the \textbf{storyboard}. This
143 involves:
144 \begin{itemize}
145 \item If work has begun on a story then the story should be
146 moved to the \textbf{In Progress} state.
147 \item If all the tasks and tests for a story are done then the
148 story should be moved to the \textbf{Done} state.
149 \end{itemize}
150 \textbf{NOTE:} The \textit{Accepted} status is for stories that
151 are closed because the Product Owner has accepted them as closed.
152 Stories will be put in this state during the sprint review.
153 \item At the end of each day (or at least before your daily scrum meeting)
154 you should make sure to update the \textbf{testboard}. This
155 involves moving the test to either the \textbf{Passed} or
156 \textbf{Failed} columns if the test has been done.
157 \item Finally, during the Sprint Review the product owner will determine
158 which items are truly done and which are not. When an item is
159 determined to be done then it can be \textbf{Closed} which will move
160 it to the \textit{Accepted} state and close all the tasks within
161 that backlog item as well.
162 \item For any items that had an \textbf{Upstream} component there should
163 be the following stories created:
164 \begin{itemize}
165 \item A story should be created to address maintainer feedback.
166 ideally the patches have been submitted early enough that
167 you will know if there will be maintainer feedback prior
168 to the next sprint planning.
169 \item A story must be created indicating the \textbf{Merged} item.
170 This story should be added to the backlog and assigned into
171 the proper epic to allow tracking of the merge of the patches
172 into the upstream tree.
173 \end{itemize}
174 \end{enumerate}
176 \paragraph{}
177 This concludes the life cycle of a story in VersionOne. If you have additional
178 questions please reach out to your scrum master for help.