Backlog Owners are responsible for:

  1. Defining, prioritizing, and updating the Product Backlog as needed. This may require the assistance of the Tech Leads, Business SMEs, and/or other stakeholders.
  2. The Backlog Owners will take responsibility for what gets implemented and is empowered to make fast, local decisions about what is built.
  3. They are also responsible for providing input to help build and maintain the product roadmap.
  4. It is important that the Backlog Owners understands the architectural and technical work that needs to be completed, since this work is often a predecessor for implementing the business features.
  5. They will facilitate the backlog grooming for each sprint and should be on a cadence on the Team's calendar. If needed, the Scrum Master can send out the invites.
  6. The Backlog Owners are responsible for ensuring all work items in the Backlog meet the Definition of Ready before being pulled into a sprint and meets the Definition of Done when accepting the Work Item in the Sprint.

Below are examples of how to breakdown User Stories, Definition of Ready, and Definition of Done.

 

Breaking Down User Stories

Strategy 1: Breaking down by workflow steps

If PBI's involve a workflow of some kind, the item can usually be broken up into individual steps. Take a PBI for an order process of a regular webshop:
As customer I can pay for the goods in my shopping basket, so that I receive my products at home
Given a fairly standard order procedure, we could identify the following steps:

  • As customer I can log-in with my account, so I don't have to re-enter my personal - information every time;
  • As customer I can review and confirm my order, so I can correct mistakes before I pay;
  • As customer I can pay for my order with a wire transfer, so that I can confirm my order;
  • As customer I can pay for my order with credit card, so that I can confirm my order;
  • As customer I receive a confirmation email with my order, so I have proof of my purchase;

Strategy 2: Breaking down by business rules

PBI's often involve a number of explicit or implicit business rules. Take this PB, again for the order process of a regular webshop:
As customer I can purchase the goods in my shopping basket, so that I can receive my products at home
Given a fairly standard order procedure, we could identify the following ‘business rules':

  • As shop owner I can decline orders below 10 dollars, because they aren't profitable;
  • As shop owner I can decline customers from outside the US, because the shipping expenses make these orders unprofitable;
  • As shop owner I can reserve ordered products from stock for 48 hours, so other customers see a realistic stock;
  • As shop owner I can automatically cancel orders for which I have not received payment within 48 hours, so I can sell them again to other customers;

Strategy 3: Breaking down by happy / unhappy flow

Functionality often involves a happy flow and one or more unhappy flows. The happy flow describes how functionality behaves when everything goes well. If there are deviations, exceptions or other problems, unhappy flows are invoked. Take this PBI for logging in to a secure website:
As customer I can log in with my account, so that I can access secured pages
If we consider a regular login procedure, we can identify a happy flow and several potential unhappy flows:

  • As user I can log in with my account, so that I can access secure pages (happy);
  • As user I am able to reset my password when my login fails, so I can try to log in again (unhappy);
  • As user I am given the option to register a new account if my login is not known, so I can gain access to secure pages (unhappy);
  • As site owner I can block users that log in incorrectly three times in a row, so I can protect the site against hackers (unhappy);

Unhappy flows describe exceptions. By identifying the various flows, we more clearly understand the required functionality. A Product Owner can more easily decide what is important right now. Perhaps blocking users after three failures is not important right now, because there are only a handful of users in the first version anyways. Or perhaps a reset of passwords can be done by sending an email to a customer care employee for the time being. Again, by splitting up functionality we can more accurately ask questions about the business value, and make decisions accordingly.

Strategy 4: Breaking down by input options / platform

Most web applications have to support various input options and/or platforms, like desktops, tablets, mobile phones or touchscreens. It may be beneficial to break down large items by their input options. Take a digital Scrum Board for a team:
As team member I can view the Scrum Board, so I know how we're doing as a team
We can identify the following input options:

  • As team member I can view the Scrum Board on my desktop, so I know the status of the sprint;
  • As team member I can view the Scrum Board on my mobile phone, so I know the status of the sprint;
  • As team member I can view the Scrum Board on a touchscreen, so I know the status of the sprint;
  • As team member I can view the Scrum Board on a print-out, so I know the status of the sprint;

Strategy 5: Breaking down by data types or parameters

Some PBI's can be split based on the datatypes they return or the parameters they are supposed to handle. Take, for example, a search function for a webshop:
As customer I can search for products so I can view and order them
There are many ways to search for a product. All these potential parameters can be considered and broken up into smaller PBI's:

  • As customer I can search for a product by its product number, so I can quickly find a product that I already know;
  • As customer I can search for products in a price range, so that the search results are more relevant;
  • As customer I can search for products by their color, so that the search results are more relevant;
  • As customer I can search for products in a product group, so that the search results are more relevant;

Strategy 6: Breaking down by operations

PBI's often involves a number of default operations, such as Create, Read, Update or Deleted (commonly abbreviated as CRUD). CRUD operations are very prevalent when functionality involves the management of entities, such as products, users or orders:
As shop owner I can manage products in my webshop, so I can update price and product information if it is changed
By identifying the individual operations required for this functionality, we can derive the following smaller bits of functionality:

  • As shop owner I can add new products, so customers can purchase them;
  • As shop owner I can update existing products, so I can adjust for changes in pricing or product information;
  • As shop owner I can delete products, so I can remove products that I no longer stock;
  • As shop owner I can hide products, so they cannot be sold for the time being;

Strategy 7: Breaking down by test scenarios / test case

This strategy is useful when it is hard to break down large PBI's based on functionality alone. In that case, it helps to ask how a piece of functionality is going to be tested. Which scenarios have to be checked in order to know if the functionality works? Take a task planning system:
As manager I can assign tasks to employees, so they can work on tasks
If we consider this functionality based on potential scenarios, we can break down the item into:

  • Test case 1: If an employee is already assigned, he or she cannot be assigned to another task;
  • Test case 2: If an employee has reported in sick, he or she should be visually marked;
  • Test case 3: If an employee has reported in sick, he or she cannot be assigned to a task;
  • Test case 4: If an employee is not yet assigned, they can be assigned to a task;
  • Test case 5: Employees can be assigned with a touchscreen monitor;

Strategy 8: Breaking down by roles

PBI's often involves a number of roles (or groups) that performs parts of that functionality. Take a PBI to publish new articles to a public newspaper website:
As news organization we can publish new articles on our homepage, so customers have a reason to return periodically
By considering the various roles that are involved, we can break the functionality down into the following bits:

  • As customer I can read a new article, so I can be informed of important events;
  • As journalist I can write an article, so it can be read by our customers;
  • As editor I can review the article before putting it on the site, so that we can prevent typos;
  • As admin I can remove articles from the site, so that we can pull offending articles;
  • As customer I can review and confirm my order, so I can correct mistakes before I pay;

Strategy 9: Breaking down by ‘optimize now' vs ‘optimize later'

Often, PBI's can be implemented in varying degrees of perfection and optimization of the functionality described. Take this PBI:
As visitor I can search for hotels in a neighborhood, so I can narrow my search
A story like this can be broken down in varying degrees of optimization:

  • As visitor I can search for hotels based within a radius from an address, so I can narrow down my search;
  • As visitor I can enter the zip code to auto-complete the address, so I don't have to enter the entire address manually;
  • As visitor I can use my location (GPS) to search in the neighborhood, so I don't have to enter the address manually;
  • As visitor I get the most-searched hotels in the neighborhood right away, while other hotels are loading in the background, so I more quickly get results;

while more complex functionality (auto-completion, GPS) is implemented in the future.

Strategy 10: Breaking down by browser compatibility

In a variation of strategy #4, PBI's for web-applications often need to work on a wide variety of browser platforms. Modern browsers tend to be more compliant to standards, and easier to develop for, while older browsers often require hacks and customizations to get everything to work properly. Take this story:
As customer I can view product details, so I know if I want to buy it
By considering the browser versions, we can break down the work into smaller items:

  • As customer I can view product details in a standards-compliant, modern browser, so I know if I want to buy it;
  • As customer I can view product details in IE7, so I know if I want to buy it;
  • As customer I can view product details in a text-browser, so I know if I want to buy it;

Other strategies

There are many other strategies that are helpful when breaking down large PBI's:

  • Break down items based on identified acceptance criteria. This may seem very obvious, but it's often the easiest and most natural way to break down a story. Mapping out acceptance criteria for a PBI requires similar strategies as the ones described in this post;
  • Break down items based on the parts that are hard to implement and the parts that are easier. It may be difficult to set up a piece of functionality in a heavily designed UI, but getting it to work with a simple UI may be easy and sufficient for now. Again, it's all about being pragmatic and delivering business value;
  • Break down items based on external dependencies. Sometimes functionality is dependent on external factors, such as implementing a consumer for a remote webservice (e.g. for electronic payment or connecting to Twitter). This may be difficult, but may not have the highest priority. Or the dependencies can be mocked for the time being;
  • Break down items based on usability requirements. This includes functionality for paging through a list of records, making a website readable for blind people or people with colorblindness or implementing breadcrumbs;
  • Break down items based on SEO requirements, such as setting up dedicated landing pages for specific keywords, setting up goals for Google Analytics or setting up XML sitemaps.

 

*INVEST was first coined by Bill Wake. INVEST stands for :