Step 1: Preparing the Product Backlog

Locked lesson.

Upgrade

About this lesson

Preparing the Product Backlog is the first step in the Agile/Scrum Sprint methodology. It includes creating and prioritizing all the Story Cards.

Quick reference

Step 1: Preparing the Product Backlog

Preparing the Product Backlog is the first step in the Agile/Scrum Sprint methodology. It includes creating and prioritizing all the Story Cards.

When to Use Step 1: Preparing the Product Backlog

When a company decides to use the Agile/Scrum methodology to complete a project, the first step is to create the Product Backlog. This Product Backlog is then used throughout the life of the project.

Instructions

Preparing the Product Backlog is the first truly unique step in an Agile/Scrum project. It is in this step that the desired project scope is set and documented in the Agile/Scrum Story Cards and prioritized Product Backlog.

  • The Product Owner gathers the needs, wants and requirements for the project from stakeholders.  The project vision is helpful for identifying project stakeholders.
    • The Product Owner is interacting with Senior Management and the Business Team throughout this process.
    • Interpersonal skills and organization skills are needed to ensure that all requirements are identified and understood.
  • Each requirement is placed on an individual Story Card.
  • Once all the Story Cards are collected, the Product Owner prioritizes those cards from number one to number last.
  • Once the Stories are written, the Product Owner can also share these with the Scrum Master so they understand the type of work and can then assist the Senior Management in Scrum Team selection.
  • This Product Backlog will be used throughout the project and normally updated after each Sprint.

 

Hints and Tips

  • Office politics often has a major effect on the prioritization of stories. Don’t prioritize based solely on politics, but don’t ignore their very real impact on the project.
  • Take the time needed to do this activity well. A poorly defined Product Backlog will lead to a project result that is rejected by the organization. This step is serious work.
  • I will continue on with the museum example.
    • Story cards were generated based upon discussions with the museum staff and volunteers and several “outsiders” looking at the website from a visitor perspective. 
    • I, as Product Owner, wrote the Story Cards. The format and approach was too new to the stakeholders and I was concerned that they would be confused and intimidated by the format. So I just met with each and then wrote up the Story.
    • They were prioritized to make sure that all of the existing functionality and information was created first before any new things like the blog and interactive map were added.
    • Here is the final list of eight stories:

Login to download
  • 00:03 Hi, this is Ray Sheen.
  • 00:05 It's on to step 1, create the product backlog.
  • 00:08 I've already described the product backlog in an earlier session.
  • 00:13 So this session will focus more on some of the how tos about collecting and
  • 00:17 prioritizing stories.
  • 00:19 Recall that it's the product owner's job to collect the lists of wants, needs,
  • 00:23 wishes, desires, and mandates for the project.
  • 00:26 They will seek out the appropriate stakeholders both inside and
  • 00:29 outside of the organization to collect the vision statement is often helpful for
  • 00:33 identifying some of the people and organizations that might be affected.
  • 00:38 Every need, requirement and
  • 00:39 deliverable must be captured on a storycard known as a product backlog item.
  • 00:44 I discussed storycards in a previous module also.
  • 00:48 The absolutely key items that are required are the description of the story and
  • 00:52 the demo criteria.
  • 00:53 The product owner must practice good listening skills.
  • 00:57 They can't let their own biases override the story they
  • 01:00 are getting from a stakeholder.
  • 01:01 They need to establish an open relationship with each stakeholder
  • 01:05 to ensure that they understand what is really needed.
  • 01:09 Next, comes the prioritization.
  • 01:11 At the end of the day, this is a judgment call by the product owner.
  • 01:16 There is no right or wrong prioritization.
  • 01:19 It is usually driven by the vision for the product and
  • 01:22 the politics in the organization and among the stakeholders.
  • 01:26 I know politics should not have anything to do with it, but it does.
  • 01:30 So the product owner needs to be aware of the politics and
  • 01:33 how to work with the different individuals.
  • 01:36 And of course, if it's a large project, it's likely to have multiple releases.
  • 01:41 I find that the multiple release approach is an ideal approach.
  • 01:45 When you have stake holders who provide vague requirements.
  • 01:48 Let them see an early release and
  • 01:50 then you will usually get excellent feedback on what is really wanted.
  • 01:56 Let's look at the roles responsibilities and deliverables.
  • 02:00 No surprise that this step is dominated by work assigned to the product owner.
  • 02:04 Scrum team members have nothing to do since they haven't been assigned yet.
  • 02:08 The Scrum Master will often ask clarifying questions, so that they can provide some
  • 02:12 advice and counsel to Senior Management in the next step of the process.
  • 02:17 But they don't have a deliverable on this step.
  • 02:19 And Senior Management works with the Product Owner as needed
  • 02:22 to ensure all the stories are captured and are clear.
  • 02:25 But the big responsibility's for the product owner.
  • 02:28 So, let's look at that more closely.
  • 02:31 They must collect the requirements, write down the story cards,
  • 02:34 prioritize them and create releases when needed.
  • 02:37 They're deliverables are the release plan, the prioritized product backlog and
  • 02:42 the original story cards.
  • 02:44 I say original because they are sometimes marked up during a Sprint.
  • 02:49 We've described all of these but I want to emphasize the importance.
  • 02:52 When the Sprint starts the Scrum team will do the stories in the priority order
  • 02:58 If stories are missing or irrelevant ones included,
  • 03:01 the final project result may be unacceptable to the organization.
  • 03:05 That is not a failing of the Scrum team.
  • 03:07 That is a failure on the part of the product owner.
  • 03:10 Now if there are multiple sprints the product owner may have an opportunity to
  • 03:14 redeem themselves on a later sprint.
  • 03:17 For a poor job of creating and prioritizing the product backlog.
  • 03:21 But the product owner shouldn't just slap something together.
  • 03:23 They need to be as thorough as possible.
  • 03:27 Let's continue with our museum website upgrade example.
  • 03:31 Recall I was the product owner.
  • 03:32 So the first thing I did was to meet with the Museum staffs and
  • 03:35 volunteers to get their list of needs for the website.
  • 03:38 I also ask some friends and family members to look at aside and
  • 03:41 give me some feedback.
  • 03:43 They represented the stake holders to who were visiting the site for the first time.
  • 03:47 Here's an example of one of the stories.
  • 03:49 We needed to get agreement on the template for what the page would look like.
  • 03:53 The key was to have a template that was responsive,
  • 03:56 meaning it would automatically resize based upon the size of the viewing device.
  • 04:01 By that I mean a phone, tablet computer, or laptop computer.
  • 04:05 Another comment was that the logo and museum color scheme should be used.
  • 04:10 Well that was one story.
  • 04:11 When I had collected all the stories I had to prioritize them.
  • 04:15 There was a discussion about the museum store,
  • 04:17 but going back to the vision statement we cleared that up quickly.
  • 04:21 The prioritization in this case came down to making sure that
  • 04:24 we had everybody on the existing site working in responsive web first.
  • 04:29 Before we added features like a blog and interactive map
  • 04:32 once ahead this prioritized backlog of stories we were ready to move forward.
  • 04:39 Preparing the product backlog is work it requires it requires lots of
  • 04:42 interaction and a product owner with a strong technical, organizational and
  • 04:47 interpersonal skills.

Lesson notes are only available for subscribers.

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

Gift this course