life-cycle-of-story: Add creation of upstream stories
[ti-agile-manual/ti-agile-manual.git] / life-cycle-of-story.tex
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.