-
Notifications
You must be signed in to change notification settings - Fork 21
/
template.html
385 lines (350 loc) · 16.8 KB
/
template.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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
<!--
Google IO 2012/2013 HTML5 Slide Template
Authors: Eric Bidelman <ebidel@gmail.com>
Luke Mahé <lukem@google.com>
URL: https://code.google.com/p/io-2012-slides
-->
<!DOCTYPE html>
<html>
<head>
<title></title>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="chrome=1">
<!--<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0">-->
<!--<meta name="viewport" content="width=device-width, initial-scale=1.0">-->
<!--This one seems to work all the time, but really small on ipad-->
<!--<meta name="viewport" content="initial-scale=0.4">-->
<meta name="apple-mobile-web-app-capable" content="yes">
<link rel="stylesheet" media="all" href="theme/css/default.css">
<link rel="stylesheet" media="only screen and (max-device-width: 480px)" href="theme/css/phone.css">
<base target="_blank"> <!-- This amazingness opens all links in a new tab. -->
<script data-main="js/slides" src="js/require-1.0.8.min.js"></script>
</head>
<body style="opacity: 0">
<slides class="layout-widescreen">
<slide class="title-slide segue nobackground">
<aside class="gdbar"><img src="images/ubm_mark.png"></aside>
<!-- The content of this hgroup is replaced programmatically through the slide_config.json. -->
<hgroup class="auto-fadein">
<h1 data-config-title><!-- populated from slide_config.json --></h1>
<h2 data-config-subtitle><!-- populated from slide_config.json --></h2>
<p data-config-presenter><!-- populated from slide_config.json --></p>
</hgroup>
</slide>
<slide class="segue dark nobackground">
<aside class="gdbar"><img src="images/ubm_mark.png"></aside>
<hgroup class="auto-fadein">
<h2>Version vs Epic vs User Story </h2>
<h3>Subtitle Placeholder</h3>
</hgroup>
</slide>
<slide>
<hgroup>
<h2>Version vs Epic vs user story vs task</h2>
</hgroup>
<article>
<p>Agile development uses four clear delivery methods to bring structure to any project: versions, sprints, epics, and user stories</p>
<ul class="build">
<li>A <span class="green"><b>version</b></span> 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. A version can be made up of multiple sprints</li>
<li>A <span class="green"><b>sprint</b></span> is a set period of time during which specific work has to be completed and made ready for review</li>
<li>An <span class="green"><b>epic</b></span> 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.</li>
<li>A <span class="green"><b>user story</b></span> (represented as an issue in Jira) captures a description of a feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. User stories are broken up into individual tasks that make up the story (represented as sub-tasks in Jira)</li>
</ul>
</article>
</slide>
<slide class="segue dark nobackground">
<aside class="gdbar"><img src="images/ubm_mark.png"></aside>
<hgroup class="auto-fadein">
<h2>Why use user stories?</h2>
</hgroup>
</slide>
<slide>
<hgroup>
<h2>Why use user stories</h2>
</hgroup>
<article>
<ul class="build">
<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>
</article>
</slide>
<slide>
<hgroup>
<h2>Creating a user story</h2>
</hgroup>
<article>
<p>The goal is to outline a particular value to the customer that a team can deliver in an iteration using a few short sentences, ideally using non-technical language. While traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally, in three stages:</p>
<ul class="build">
<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>
</ul>
</article>
</slide>
<slide>
<hgroup>
<h2>What makes a great user story</h2>
</hgroup>
<article>
<p>They don't go into detailed requirements.</p>
<p>User stories must be written using the following template:</p>
<ul class="build">
<li>As a <span class="green">[type of user]</span>, I want <span class="green">[goal]</span> so that I <span class="green">[receive benefit]</span>.</li>
</ul>
<p>Let's use a website as a simple example to create a user story</p>
<ul class="build">
<li>As a <span class="green">consumer</span>, I want <span class="green">to be able to create an account</span> so that I <span class="green">can see the purchases I made in the last year to help me budget for next year</span>.</li>
</ul>
</article>
</slide>
<slide>
<hgroup>
<h2>A well-formed user story will follow the INVEST mnemonic</h2>
</hgroup>
<article class="">
<P>I – Independent</p>
<ul class="build">
<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>
<p>N – Negotiable</p>
<ul class="build">
<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>
</article>
</slide>
<slide>
<hgroup>
<h2>A well-formed user story will follow the INVEST mnemonic</h2>
</hgroup>
<article class="">
<p>V – Valuable</p>
<ul class="build">
<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>
</article>
</slide>
<slide>
<hgroup>
<h2>A well-formed user story will follow the INVEST mnemonic</h2>
</hgroup>
<article class="">
<p>E – Estimable</p>
<ul class="build">
<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>
</article>
</slide>
<slide>
<hgroup>
<h2>A well-formed user story will follow the INVEST mnemonic</h2>
</hgroup>
<article class="smaller">
<p>S – Small</p>
<ul class="build">
<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>
<p>T – Testable</p>
<ul class="build">
<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>
</article>
</slide>
<slide>
<hgroup>
<h2>User story outline</h2>
</hgroup>
<article>
<ul>
<li>User Story</li>
<li>End user goal</li>
<li>End business goal</li>
<li>Acceptance Criteria /this isn't finalized until the story is ready for development/</li>
<li>Measurement of Success /this is added after conversations with product, ux and research/</li>
</ul>
</article>
</slide>
<slide class="segue dark quote nobackground">
<aside class="gdbar right bottom"><img src="images/ubm_mark.png"></aside>
<article class="flexbox vleft auto-fadein">
<q>
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.
</q>
<div class="author">
Kent Beck
</div>
</article>
</slide>
<slide class="segue dark nobackground">
<aside class="gdbar"><img src="images/ubm_mark.png"></aside>
<hgroup class="auto-fadein">
<h2>User story dos and don’ts</h2>
<h3>Subtitle Placeholder</h3>
</hgroup>
</slide>
<slide>
<hgroup>
<h2>User story dos and don'ts</h2>
</hgroup>
<article class="">
<ul class="build">
<li><span class="green">DO</span> focus on a specific user
<ul>
<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>
</ul>
</li>
<li><span class="green">DO</span> provide acceptance criteria
<ul>
<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>
</ul>
</li>
<li><span class="green">DO</span> have conversations
<ul>
<li>update acceptance criteria and user story details based on your conversations</li>
</ul>
</li>
</ul>
<ul class="build">
<li><span class="red">DON'T</span> go into detailed requirements</li>
<li><span class="red">DON'T</span> provide the solution
<ul>
<li>User stories must be focused on the user need and benifit not solution</li>
</ul>
</li>
</ul>
</article>
</slide>
<slide class="segue dark nobackground">
<aside class="gdbar"><img src="images/ubm_mark.png"></aside>
<hgroup class="auto-fadein">
<h2>User story examples</h2>
<h3>Subtitle Placeholder</h3>
</hgroup>
</slide>
<slide>
<hgroup>
<h2>Epic example in Jira</h2>
<h3>PRNCOM</h3>
</hgroup>
<article>
<iframe data-src="https://prnewswire.jira.com/browse/PRNCOM-4564"></iframe>
</article>
</slide>
<slide>
<hgroup>
<h2>Story example in Jira</h2>
<h3>PRNCOM</h3>
</hgroup>
<article>
<iframe data-src="https://prnewswire.jira.com/browse/PRNCOM-4869"></iframe>
</article>
</slide>
<slide>
<hgroup>
<h2>Story example with wireframes in Jira</h2>
<h3>CNW</h3>
</hgroup>
<article>
<iframe data-src="https://prnewswire.jira.com/browse/CNW-58"></iframe>
</article>
</slide>
<slide>
<hgroup>
<h2>Epic example in Jira</h2>
<h3>Agility</h3>
</hgroup>
<article>
<iframe data-src="https://prnewswire.jira.com/browse/CWP-6196"></iframe>
</article>
</slide>
<slide>
<hgroup>
<h2>Story example in Jira</h2>
<h3>Agility</h3>
</hgroup>
<article>
<iframe data-src="https://prnewswire.jira.com/browse/CWP-6297"></iframe>
</article>
</slide>
<slide>
<hgroup>
<h2>Story example in Jira</h2>
<h3>Agility</h3>
</hgroup>
<article>
<iframe data-src="https://prnewswire.jira.com/browse/CWP-6207"></iframe>
</article>
</slide>
<slide>
<hgroup>
<h2>Story example in Jira</h2>
<h3> Visibility Reports</h3>
</hgroup>
<article>
<iframe data-src="https://prnewswire.jira.com/browse/VREP-3474"></iframe>
</article>
</slide>
<slide>
<hgroup>
<h2>Story example in Jira</h2>
<h3> Visibility Reports</h3>
</hgroup>
<article>
<iframe data-src="https://prnewswire.jira.com/browse/VREP-2674"></iframe>
</article>
</slide>
<slide class="segue dark nobackground">
<aside class="gdbar"><img src="images/ubm_mark.png"></aside>
<hgroup class="auto-fadein">
<h2>In-session exercise</h2>
<h3>Subtitle Placeholder</h3>
</hgroup>
</slide>
<slide>
<hgroup>
<h2>In-session exercise</h2>
</hgroup>
<article>
<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>
</article>
</slide>
<slide class="thank-you-slide segue nobackground">
<aside class="gdbar right"><img src="images/ubm_mark.png"></aside>
<article class="flexbox vleft auto-fadein">
<h2><Thank You!></h2>
<p>Important contact information goes here.</p>
</article>
<p class="auto-fadein" data-config-contact>
<!-- populated from slide_config.json -->
</p>
</slide>
<slide class="backdrop"></slide>
</slides>
<script>
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXXX-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
<!--[if IE]>
<script src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script>
<script>CFInstall.check({mode: 'overlay'});</script>
<![endif]-->
</body>
</html>