Writing Story Cards

Quick reference

• 00:04 Hi, this is Ray Sheen.
• 00:06 We've already described the elements of a story card and discussed its importance.
• 00:10 I would now like to focus on what the product owner should include when they
• 00:14 write a story card.
• 00:16 My emphasis in this session is on the product owner and
• 00:19 what they are doing with story cards.
• 00:21 The Product Owner is responsible for completing four areas of the story card,
• 00:26 the story, demo criteria, category, and priority.
• 00:31 These should be completed prior to sprint planning.
• 00:33 The product owner can modify and
• 00:35 revise these up until the time the story card is selected for a sprint.
• 00:39 Once it is part of a sprint, the product owner cannot revise any of these without
• 00:43 agreement from the scrum team.
• 00:45 And just to be clear,
• 00:46 the product owner does not estimate the amount of effort to complete the story.
• 00:50 Only the scrum team members can do that.
• 00:53 In an earlier session,
• 00:54 we discussed the product owner's interaction with stakeholders.
• 00:57 The stakeholders are normally the individuals that identify
• 00:59 the need for a story.
• 01:01 However, the actual information on the story card is the responsibility of
• 01:04 the product owner.
• 01:06 They will need to explain the story to the scrum team.
• 01:09 The product owner needs to be certain that the story is clear and
• 01:12 the demo criteria makes sense.
• 01:15 Even though a story card is crystal clear,
• 01:17 the scrum team members will still have questions.
• 01:20 That is the reason for the notes section on the story card.
• 01:23 Capture the questions and answers in the notes section.
• 01:27 The section is to be used by the scrum team for clarification.
• 01:30 The product owner is often providing the answers to many of the questions and
• 01:34 comments in the notes section.
• 01:37 So let's get down to the actual writing.
• 01:40 First, let me remind you that it's called a story card for a reason.
• 01:44 Although it documents a project requirement, it is not a stale,
• 01:47 dry statement like those often found in standards and requirements documents,
• 01:51 they are almost unintelligible.
• 01:53 It is a story about what the customer or user wants to do.
• 01:58 The story portion of the card is written in terms of the outcome or result.
• 02:02 I recommend the format, as a customer, manager, user or
• 02:06 whatever role, I want to, the action or activity that the product must perform,
• 02:11 in order to, the impact or result of completing the action or activity.
• 02:16 Essentially, why the customer, manager or user is trying to do the action.
• 02:20 This part of the story card describes what the product should do.
• 02:25 The demo criteria defines how we can check that the product is doing the story.
• 02:29 Again, this section is sometimes called the definition of done.
• 02:33 I like to use this format when writing demo criteria.
• 02:36 Given, context or setup of the demo.
• 02:40 When this happens, the event or action the product owner will take, then this occurs,
• 02:45 the result that can be observed or
• 02:46 measured that indicates that the product is doing what it should be doing.
• 02:51 The category section can be used in several different ways but
• 02:54 it's most commonly used to provide some focus on the inherent value of the story.
• 02:59 There are two acronyms that are used to categorize stories, and
• 03:03 I have illustrated both of them already.
• 03:05 In my opinion, they are both equally acceptable so use whichever you prefer.
• 03:10 MoSCoW stands for must have, should have, could have, and won't have.
• 03:15 This one makes more sense at the sprint level,
• 03:18 when a story is not apart of the backlog but is part of the product backlog.
• 03:22 The other acronym is MuSCoWa, which stand for
• 03:26 must have, should have, could have and want to have.
• 03:30 This works well for the product backlog or the sprint backlog.
• 03:34 As you can see, the only difference is the final w.
• 03:36 There isn't much difference between could have and want to have.
• 03:41 However, it doesn't make sense to have a story that is categorized as won't have
• 03:46 in the product backlog.
• 03:47 If you won't have it, it shouldn't be in that backlog.
• 03:52 The final element to mention is priority.
• 03:54 We've already discussed that in depth.
• 03:56 The one comment I want to make is that every story
• 03:59 is first prioritized within the product backlog.
• 04:03 Once the sprint starts, the stories of the sprint are prioritized for
• 04:06 the sprint backlog, and the priorities may change between these two
• 04:10 depending upon the focus of the sprint or release.
• 04:14 Let's look at a few examples.
• 04:16 In this project, we're creating a business intelligence dashboard for
• 04:20 an IT organization.
• 04:21 Let's look at the first story.
• 04:23 As a user, I want to view system status in order to know if a system is down.
• 04:28 The story follows our format, and it is clear the result that we want to achieve.
• 04:33 The demo criteria is,
• 04:35 when viewing systems status screen, when a system goes down its color turns red.
• 04:40 Notice, it is not describing what the user will do about it,
• 04:43 just what the system does.
• 04:45 The category is must.
• 04:47 If we want a dashboard of our IT system,
• 04:49 we clearly want to know which systems are up and which are down.
• 04:54 Let's look at the next story.
• 04:56 In this case, a manager has a need.
• 04:58 As a manager, I want status updates every second in order to identify trends.
• 05:04 Notice that in this case the manager is not describing the screens or
• 05:08 any other update indicators but is focused on the activity and its frequency.
• 05:13 The demo criteria is, when viewing any screen, if a system status changes,
• 05:18 the color changes within a second.
• 05:20 Note that the demo criteria is focused on status change.
• 05:23 So if a system that was offline comes online,
• 05:27 the online status needs to update with in one second also.
• 05:31 In this case the category was Should.
• 05:34 This indicates that there's a little wiggle room.
• 05:36 If the scrum team came back and said that they couldn't get it within one second but
• 05:41 could get it within two seconds,
• 05:42 the product owner would probably agree to the change.
• 05:46 Once the entire backlog is collected, the priority can be set.
• 05:49 In this case, the must have is number one, and the should have story is number two.
• 05:55 Writing Story Cards is harder than it looks.
• 05:59 In order to clearly communicate what should happen and how it will be checked,
• 06:03 the product owner is forced to think through the requirements and
• 06:07 its implications.
• 06:08 Well-written stories help the scrum team
• 06:12 deliver a product that meets the stakeholders' needs and expectations.

Lesson notes are only available for subscribers.