|
1 | 1 | :::row::: |
2 | 2 | :::column::: |
3 | | -  |
| 3 | +  |
4 | 4 | :::column-end::: |
5 | 5 | :::column span="3"::: |
6 | 6 |
|
7 | | -User stories are the base artifacts for Agile planning. A user story is a high-level definition of a requirement. It should contain enough information that the requirement is understood, and a reasonable estimate of the effort required to build it can be made. |
| 7 | +User stories are the base artifacts for Agile planning. A user story is a high-level definition of a requirement. It should contain enough information that the requirement is understood and a reasonable estimate of the effort required to build it can be made. |
8 | 8 |
|
9 | | -User stories are written throughout the development life cycle, but the core of them are written when you create an epic. Typically, the whole team involved, and often stakeholders from the business or even customers, and the stories are written in a workshop-like forum. Further stories will evolve as the epic proceeds, to address new requirements or to split existing stories that have become too complex. Some stories will even evolve into epics in their own right if they turn out to be complex or emerge as functionality worth extending. |
| 9 | +User stories are written throughout the development lifecycle, but most of them are written when you create an epic. Typically, the whole team is involved, often including stakeholders from the business or even customers. The stories are written in a workshop-like forum. Further stories will evolve as the epic proceeds to address new requirements or to split existing stories that have become too complex. Some stories will even evolve into epics in their own right if they turn out to be complex or emerge as functionality worth extending. |
10 | 10 |
|
11 | 11 | :::column-end::: |
12 | 12 | :::row-end::: |
13 | 13 |
|
14 | 14 | A good user story contains: |
15 | 15 |
|
16 | | -* Summary of the requirement, no more than one or two sentences. |
17 | | -* Priority, to tell us how important the story is to the product. |
18 | | -* Series of "stories" about the requirement, that describes what we expect from it. |
19 | | -* Test of the story's success. |
20 | | -* Estimate of the effort the story will take. |
| 16 | +* A summary of the requirement, no more than one or two sentences. |
| 17 | +* A priority to tell us how important the story is to the product. |
| 18 | +* A series of "stories" about the requirement that describes what we expect from it. |
| 19 | +* A test of the story's success. |
| 20 | +* An estimate of the effort the story will take. |
21 | 21 |
|
22 | | -Let’s look at an example story for our recommendation engine. |
| 22 | +Let’s look at an example story for our recommendation engine: |
23 | 23 |
|
24 | | -* Summary: Build a content-based recommendation algorithm. |
| 24 | +* Summary: Build a content-based recommendation algorithm. |
25 | 25 | * Priority: 1 |
26 | | -* Stories |
27 | | - * As a customer, I want to see recommendations based on my prior purchases, so I can find the best items to buy. |
28 | | - * etc. ... |
| 26 | +* Stories: |
| 27 | + * As a customer, I want to see recommendations based on my prior purchases so I can find the best items to buy. |
29 | 28 | * Test: The algorithm returns three content-based recommendations for a customer’s user ID. |
30 | | -* Estimate: 3 days. |
| 29 | +* Estimate: three days. |
31 | 30 |
|
32 | 31 | ## Subject |
33 | 32 |
|
34 | | -Our user story starts with a summary of the objective of the story, in our case building a recommendation algorithm. |
| 33 | +Our user story starts with a summary of the objective of the story; in our case, building a recommendation algorithm. |
35 | 34 |
|
36 | 35 | ## Priority |
37 | 36 |
|
38 | | -We give the story a priority, here `1`. This priority is derived from the prioritization frameworks we discussed earlier in the module. Remember in our 2x2 prioritization plot that stories in the top-left quadrant were the most important, here priority `1` would likely be one of those stories. |
| 37 | +We give the story a priority; here, `1`. This priority is derived from the prioritization frameworks we discussed earlier in the module. Remember in our 2x2 prioritization plot that stories in the top-left quadrant were the most important; here, priority `1` would likely be one of those stories. |
39 | 38 |
|
40 | 39 | ## Stories |
41 | 40 |
|
42 | 41 | We then list a series of "stories" about the feature we're building. Those "stories" typically follow a format something like: |
43 | 42 |
|
44 | 43 | > As a < type of user >, I want < some goal > so that < some reason > |
45 | 44 |
|
46 | | -They tell the story of what the user wants, expects, and needs from the requirement. |
| 45 | +They tell the story of what the user wants, expects, and needs from the requirement. |
47 | 46 |
|
48 | 47 | ## Test |
49 | 48 |
|
50 | 49 | The test of the story is the acceptance criteria, which indicates successful completion of the story. In our case, our algorithm returning three recommendations for each user. Other tests might include the accuracy of the feature or its performance. |
51 | 50 |
|
52 | 51 | ## Estimate |
53 | 52 |
|
54 | | -The estimate is the amount of effort we believe the story will take to complete. Estimates can be complicated and hard to get right. There are [many](https://www.berteig.com/how-to-apply-agile/9-agile-estimation-techniques/) [ways](https://techbeacon.com/app-dev-testing/fast-estimation-better-approach-agile-estimation) of estimating work. A simple, initial, approach is to estimate the amount of time a story will take in days and/or hours. Initially, your estimates might be a little imprecise but as you complete stories you can validate your estimates against reality. This process will hopefully help you refine and develop more accurate estimates over time. |
| 53 | +The estimate is the amount of effort we believe the story will take to complete. Estimates can be complicated and hard to get right. There are [many](https://www.berteig.com/how-to-apply-agile/9-agile-estimation-techniques/) [ways](https://techbeacon.com/app-dev-testing/fast-estimation-better-approach-agile-estimation) of estimating work. A simple initial approach is to estimate the amount of time a story will take in days and/or hours. Initially, your estimates might be a little imprecise, but as you complete stories, you can validate your estimates against reality. This process will hopefully help you refine and develop more accurate estimates over time. |
55 | 54 |
|
56 | 55 | > [!WARNING] |
57 | | -> Estimates can be contentious. It's often hard to estimate how much effort is involved in a story. If you or the team get it wrong then avoid recriminations. Instead, focus on identifying why the estimate was wrong and doing better next time. More learning, less blame. |
| 56 | +> Estimates can be contentious. It's often hard to estimate how much effort is involved in a story. If you or the team get it wrong, avoid recriminations. Instead, focus on identifying why the estimate was wrong and doing better next time; more learning, less blame. |
58 | 57 |
|
59 | 58 | Your estimates also help you crudely ascertain how many people you need building your product. If you want to build 20 stories in a month that require more effort than your team can deliver, then you know you need to hire more people to build your product. |
60 | 59 |
|
61 | 60 | ## Summary |
62 | 61 |
|
63 | 62 | This story is a formal user story; many organizations use more lightweight and informal representations. If a story feels like it has too much detail, then the traditional approach is to split the story into smaller stories. |
64 | 63 |
|
65 | | - |
| 64 | + |
66 | 65 |
|
67 | | -From here, we can now also see the whole structure of a road map, and how each component, from user stories to the mission rolls up into the plan to build your product. |
| 66 | +From here, we can now also see the whole structure of a roadmap, and how each component from user stories to the mission rolls up into the plan to build your product. |
0 commit comments