Focus video player for keyboard shortcuts
Auto
  • 720p
  • 540p
  • 360p
1.00x
  • 0.50x
  • 0.75x
  • 1.00x
  • 1.25x
  • 1.50x
  • 1.75x
  • 2.00x
cc

We hope you enjoyed this lesson.

Get the Project Planning course for more great video tutorials.

Start free trial

Cool lesson, huh? Share it with your friends

About this lesson

Story Cards - also known as Product Backlog Items (PBIs) - are the technique used for documenting project scope, quality requirements, estimates, and priority of the deliverables in an Agile/Scrum project.

Exercise files

Download this lesson’s related exercise files.

Story Cards
59.3 KB Story Cards - Solution
96.6 KB

Quick reference

Story Cards

Story Cards, also known as Product Backlog Items (PBIs) are the technique used for documenting project scope, quality requirements, estimates, and priority of the deliverables in an Agile/Scrum project.

When to Use Story Cards

The Product Owner uses Story Cards to define the project scope, the Scrum team uses Story Cards to estimate the effort, and the Scrum Master uses Story Cards to track schedule progress on the project.

Instructions

As the Product Owner gathers inputs from stakeholders throughout the business, he or she initiates a story card for each deliverable. The deliverable could be an actual item to be created or it could be a performance characteristic within a large project deliverable. 

It is through the Story Cards that project scope is identified. The project team will often create additional Story Cards that represent infrastructure or background activities that must occur in order to do the deliverable Stories.  The Story Cards are sometimes deployed into activity stories for ease of estimating and control. 

A critical aspect of the Stories in the Agile/Scrum approach is that the Stories will be prioritized from number one to number last – with no ties. That is often the most challenging element of creating Story Cards.  That prioritization is done by the Product Owner, not the Scrum team or Scrum Master.

The diagram below shows a typical Story Card.  The actual format varies based upon local practice, but it normally includes these fields.

  • The “Story” is the description of the deliverable.  It is often written as a description of what should happen when a user takes a certain action.
  • The “Demo Criteria” embodies the quality control requirements for the Story. It describes the pass or fail conditions that will indicate if the story had been successfully developed.
  • The “Category” is used by the Product Owner to classify Stories. This can be done in several ways including categorizing by Release and categorizing by the need for the story.
  • The “Priority” of the Story is set by the Product Owner and can change from Sprint to Sprint.
  • The “Estimate” is created by a Scrum team member and is normally described in terms of the number of hours of work (or some other measure of effort). This estimate is revised daily once a story has been started and will then indicate an estimate of the remaining work.
  • The “Notes” section is often used by the Scrum team during planning and execution to keep track of special items associated with the Story.

Hints and Tips

  • I prefer to use actual cards or paper for my Story Cards. It is easier for the entire team to see what each one says and during the Sprint it is easier for everyone to see the status. If you use a Scrum program to track the Story Cards, be certain that you project the screen on the wall of the room where the Scrum meeting takes place so everyone can see the status.  
Login to download
  • 00:04 Hello, I'm Ray Sheen.
  • 00:05 I want to discuss story cards.
  • 00:07 This is a tool that is used to manage scope, schedule, and resources.
  • 00:11 It is the fundamental building block of an agile scrum project.
  • 00:15 So let's get started.
  • 00:17 First, the professional technical term is a product backlog item,
  • 00:21 but everyone calls them story cards.
  • 00:24 All of the deliverables from all of the stakeholders are listed on a story card.
  • 00:28 One story card per deliverable.
  • 00:30 If it isn't on a story card, then it will not be done as part of the project.
  • 00:35 That is why we say the story cards describe the scope of the project.
  • 00:39 And I'll show you in a minute that the story card will include an estimate which
  • 00:43 is to manage resources.
  • 00:45 And the stories are moved through different stages of a project which
  • 00:49 gives us our schedule status.
  • 00:51 When we get into the sprint planning,
  • 00:53 you'll find that sometimes Story Cards are not just a story, they're an epic.
  • 00:58 When that happens, the story card will get deployed into chapters.
  • 01:02 And even then the stories are often further deployed into activities in order
  • 01:07 to further describe the scope.
  • 01:09 A classic example of deliverable deployment.
  • 01:12 The story cards are prioritized by the product owner from the highest priority to
  • 01:17 the lowest, number one to number last, and there are no ties allowed.
  • 01:21 This will be important information as the team manages the work within the time box.
  • 01:26 The lowest priority item often are not completed in order to ensure
  • 01:31 the high priority items are done, and are done right.
  • 01:34 So let's take a look at each of the elements of a story card.
  • 01:38 The story is the description of the deliverable is often written as
  • 01:41 a description of what should happen when a user takes a certain action.
  • 01:45 The product owner will usually write this based upon their discussions with
  • 01:49 the various stakeholders.
  • 01:51 The Demo Criteria embodies the quality control requirements for the story.
  • 01:55 It describes the pass or
  • 01:56 fail conditions that will indicate that the story has been successfully developed.
  • 02:01 Again, this is written by the product owner.
  • 02:04 The Category is used by the product owner to classify stories.
  • 02:08 This can be done in several different ways including categorization by release and
  • 02:13 categorization by the need for every story such as a must have, should have,
  • 02:18 nice to have designation.
  • 02:20 The Priority of the story is also set by the product owner.
  • 02:24 This can change from sprint to sprint, but it's always set by the product owner.
  • 02:29 The Estimate is created by the scrum team members not the product owner or
  • 02:33 scrum master, and it is normally described in terms of the number of hours of work or
  • 02:38 some other measure of effort.
  • 02:40 This estimate is revised daily, once the story has been started.
  • 02:43 And will then indicate an estimate of the remaining hours of work until the story is
  • 02:47 complete.
  • 02:48 The Notes section is often used by the scrum team during planning and
  • 02:52 execution to keep track of special items associated with this story.
  • 02:55 It can contain anything that the scrum team finds helpful.
  • 02:59 The story card is not only used in planning, it will be used for
  • 03:02 tracking the sprint progress on the scrum board.
  • 03:05 In that regard, it's similar to the WBS dictionary,
  • 03:09 which you may recall has columns for scope, schedule, resources, and status.
  • 03:14 The story card is the basic building block of Agile Scrum planning and tracking.
  • 03:19 They're the point of integration of scope, schedule,
  • 03:25 and resources, the classic project triple constraint.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course