forked from awkale/user-story-best-practice
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME.html
152 lines (123 loc) · 9.87 KB
/
README.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
</head>
<body>
<h1 id="userstorybestpracticedocumentationandpresentation">User Story Best Practice documentation and presentation</h1>
<p><a href="http://prnewswire-ux.github.io/user-story-best-practice">documentation site</a></p>
<h2 id="versionthemevsepicvsuserstoryvstask">Version (theme) vs Epic vs user story vs task</h2>
<p>Agile development uses four clear delivery vehicles to bring structure to any agile project: user stories, sprints, epics, and versions.
* A version is a set of features and fixes released together as a single update to your product. Assigning issues to versions helps you plan the order in which new features (stories) for your product will be released to your customers.
* An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic.
* In JIRA Agile, a story is represented as an issue, and individual tasks within the story are represented as sub-tasks.
* A sub-task issue is typically one of many tasks that make up a story (or parent issue).</p>
<h2 id="whyuseuserstories">Why use user stories?</h2>
<ul>
<li>Keep yourself expressing business value</li>
<li>Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution</li>
<li>Avoid the appearance of false completeness and clarity</li>
<li>Get to small enough chunks that invite negotiation and movement in the backlog</li>
<li>Leave the technical functions to the architect, developers, testers, and so on</li>
</ul>
<h2 id="whatisauserstory">What is a user story?</h2>
<ul>
<li>A user story represents a small piece of business value that a team can deliver in an iteration. While traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally, in three stages:</li>
<li>The brief description of the need</li>
<li>The conversations that happen during backlog grooming and iteration planning to solidify the details</li>
<li>The tests that confirm the story’s satisfactory completion</li>
<li>The goal of a user story is to deliver a particular value back to the customer.</li>
<li>A story or user story is a software system requirement that is expressed in a few short sentences, ideally using non-technical language.</li>
</ul>
<h2 id="whatmakesagreatuserstory">What makes a great user story</h2>
<ul>
<li><p>They don’t go into detailed requirements.</p></li>
<li><p>User stories must be written using the following template:</p>
<blockquote>
<p>As a [type of user], I want [goal] so that I [receive benefit].</p>
</blockquote></li>
<li><p>Let’s use a website as a simple example to create a user story.</p>
<blockquote>
<p>As a consumer, I want to be able to create an account so that I can see the purchases I made in the last year to help me budget for next year.</p>
</blockquote></li>
</ul>
<blockquote>
<p>“Stories are deliberately not fleshed out in detail until they are ready to be developed, you only need enough understanding to allow prioritization with other stories.” - Kent Beck</p>
</blockquote>
<ul>
<li><p>A well-formed user story will follow the INVEST mnemonic.</p></li>
<li>I – Independent
<ul>
<li>Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.</li>
</ul></li>
<li>N – Negotiable
<ul>
<li>A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.</li>
</ul></li>
<li>V – Valuable
<ul>
<li>A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important. This is especially an issue when splitting stories.</li>
<li>Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.</li>
</ul></li>
<li>E – Estimable
<ul>
<li>A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate.</li>
<li>Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience. (Sometimes a team may have to split a story into a (time-boxed) “spike” that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)</li>
</ul></li>
<li>S – Small
<ul>
<li>Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than a month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.</li>
</ul></li>
<li>T – Testable
<ul>
<li>A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive.</li>
<li>“Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met. If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing. A team can treat non-functional requirements (such as performance and usability) as things that need to be tested. Figure out how to operationalize these tests will help the team learn the true needs.</li>
</ul></li>
<li><p>User story outline</p></li>
<li><p>User Story</p></li>
<li><p>End user goal</p></li>
<li><p>End business goal</p></li>
<li><p>Acceptance Criteria /this isn’t finalized until the story is ready for development/</p></li>
<li><p>Measurement of Success /this is added after conversations with product, ux and research/</p></li>
</ul>
<h2 id="userstorydosanddon’ts">User story dos and don’ts</h2>
<ul>
<li>DO focus on a specific user</li>
<li>Avoid the generic role of User when writing user stories. User stories are about all of the role who interact with the system or who realize some value or benefit from the system.</li>
<li>DO provide acceptance criteria</li>
<li>The product owner should list as many acceptance criteria as possible in order to clarify the intent of the story. Acceptance criteria will become QA test cases</li>
<li>DO have conversations</li>
<li>update acceptance criteria and user story details based on your conversations</li>
<li>DONT go into detailed requirements</li>
<li>DONT provide the solution</li>
<li>User stories must be focused on the user need and benifit not solution</li>
</ul>
<h2 id="advantagesofjiratipsandtricks">Advantages of Jira; tips and tricks</h2>
<ul>
<li>Type <code>c</code> for shortcut to creating an issue</li>
<li>Add issue to epic - via backlog agile board or when viewing story</li>
<li>take advantage of Jira’s text formatting for easy to follow descriptions</li>
</ul>
<h2 id="examplesofbestinclassandineffectiveuserstories">Examples of best in class and ineffective user stories</h2>
<ul>
<li><a href="https://prnewswire.jira.com/browse/PRNCOM-4564">epic - As a customer of PR Newswire, I would like a new news release template for my thought leadership content</a>
<ul>
<li><a href="https://prnewswire.jira.com/browse/PRNCOM-4869">story - As a user I want to be able to see that there is more information below the cropping of an infographic so that it is easier to know that it should be enlarged</a></li>
</ul></li>
<li><a href="https://prnewswire.jira.com/browse/CNW-58">UX wireframes</a></li>
<li>Agility: Epic-Audience Data
*<a href="https://prnewswire.jira.com/browse/CWP-6297">story - As a monitoring user, I would like to see mentions with ComScore audience data available within my results, so that I can qualify the message based on reach of the outlet.</a></li>
<li>Visibility Reports: Earned Media, International Release Consolidation</li>
<li>(Too technical)<a href="https://prnewswire.jira.com/browse/VREP-3474">Earned Media Pickup processing and analysis</a></li>
<li>(As a wire customer I want to understand the full value and impact of a PRN distribution so my purchase decision is validated)[https://prnewswire.jira.com/browse/VREP–2674]</li>
</ul>
<h2 id="in-sessionexerciseyou’lllead:">IN-SESSION EXERCISE YOU’LL LEAD:</h2>
<ul>
<li>Break into groups of 2–3</li>
<li>Share the features you brought with the group</li>
<li>Group decides on 1 feature</li>
<li>As a group write an epic and a few user stories</li>
<li>Review epic and user stories and dicuss</li>
</ul>
</body>
</html>