How To Break Down Product Backlog Items in Scrum?

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;

By breaking down functionality into the roles that have to perform bits of that functionality, we more clearly understand what functionality is needed and can more accurately estimate the work involved. Writing PBI’s is a great way to apply this strategy. It also helps the Product Owner to prioritize. Some roles may be less relevant at the moment, and can be implemented later. Perhaps there is no need at the time for an editor. Or the editor can be called by a journalist to check the article manually.

Breaking down by functionalities: 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;

By breaking down the search functionality in this manner, we more clearly understand what kind of search parameters will be used. This allows us to more accurately estimate the functionality, but it also allows a Product Owner to make decisions about priority. Maybe paging is not yet relevant because of the small number of products. It might become relevant when the number of products grows. Or maybe some of the search functionality can be implemented in a simplified manner for now. Another example of this strategy is when breaking up functionality involving management information based on the returning data types. Some of the information can be presented visually in charts or graphs (data types), but can also be displayed in a tabular format (datatype) for now. Perhaps the Product Owner is ok with exporting the data to Excel and manually creating all the graphs and charts there for the time being.