My last article provided an overview and explanation of the Product Owner role within the Scrum Framework. In this article I will discuss the Product Backlog. The Product Owner is responsible for maintaining and prioritizing the Product Backlog, which can be a daunting responsibility, but she doesn’t need to create it alone. The biggest challenge with the Product Backlog is getting it started, and after that, it should become second nature to continue adding to it and refining it. Here is a simple guide to help the Product Owner start this process and ensure that the backlog continues to be healthy as the sprints increase.
Starting the Product Backlog
The Product Backlog is the master list of all the user stories and the high level descriptions of functionality. The Product Owner will gather the information regarding the needs for the project and will start writing user stories to communicate the vision, the goal being to identify and describe the requirements.
A user story is a great way of describing what the users want. Writing a user story is simple, just use the formula: As a
Two examples of user stories:
- As an anonymous user, I want to see the latest news articles on the homepage so that I don’t have to view older articles that I may have already read.
- As a logged in user, I want to see a link to my user profile at the top of the page, so that I can easily find access and change my personal information.
When the Product Owner starts thinking in these terms, it’s not only a great way to communicate the requirements in a non-technical way, but it also helps other people fully understand why a requirement is being requested. Also with this format, the Product Owner can request help from stakeholders in documenting their requests.
A key element in creating the Product Backlog is to know the customer. But what if the Product Owner is unsure about what the customer wants or needs? She should start talking to people and asking questions. In many cases it makes sense to have conversations with the customers, to get their feedback. If this isn’t possible, another option is to write out customer profiles. She should also talk to the tech team and people within the organization (management, customer support people, etc.) to get more input.
Steps to Creating the Product Backlog
- Put yourself in the user’s mindset – know the customer! Ask yourself what the user wants
- Start easy – write down everything that comes to mind. Be specific and ask for input
- Identify all of the different users (logged in/out, admin, staff, contributors, customers, etc.)
- Place a business value to these user stories – how important is this to the organization? i.e. Being able to login might be a high priority and labeled as a Very High, whereas being able to rate an article may be a low priority and labeled as a Very Low
- Adjust priorities when new business needs arise
- Continuously go back to the Product Backlog for grooming (add, delete, re-prioritize)
Product Backlog Reminders
- There should only be a single Product Backlog – it can be organized in a way that makes sense to separate out functional and technical requirements if needed, but there shouldn’t be more than one backlog
- User Stories can be written on index cards or put in a ticketing system
- Anyone can create user stories, but the Product Owner is the only one to place business values on them
- It’s okay (and expected) for the values on user stories to change as things change within the organization
The first sprint can start once the product backlog is flush with the current highest priorities. Once the sprint begins, the Product Owner now needs to start thinking about the next sprint and ensure that the details are in place for those requirements. She’ll be updating the backlog and assessing the priorities as new business needs arise – continuing to get feedback from stakeholders and asking for input when needed!
This is the third in a series of posts about Scrum. For the first, please see The Three Elements Of Scrum.