Writing Story Cards

Quick reference

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

Lesson notes are only available for subscribers.