Scrum Rules: The Top Product Backlog Items Are Refined

Product Backlog Items (PBIs) that are at the top of the Product Backlog (in other words, those which are to be done next), need to be small enough that the Scrum Team can comfortably complete all the work for them within a single Sprint.

The Product Owner should be spending a little time every Sprint to split “large” PBIs into small PBIs. The Product Owner relies on the team to estimate if they are small enough. If the PBIs are not small enough then large problems can arise. Probably the most serious problem is that the Scrum Team may be unable to start and finish PBIs in a single Sprint which can seriously hinder the “inspect and adapt” process due to Sprint results that cannot be demonstrated in the Sprint Review. Almost as bad, incomplete work can leave a mess in the system if the Product Owner for some reason decides to change priorities and not complete work started in a previous Sprint. Finally, incomplete work dis-empowers the Product Owner from being able to make a business-based decision to ship or deploy the Team’s work at the end of the Sprint. A smaller problem that can arise from PBIs that are large is that the Team may not be able to fill their Sprint as effectively. One way to think about this is the difference in how much empty space there is in a cup filled with large pebbles versus a cup filled with sand. The rule of thumb is that PBIs should be small enough that between five and ten fit into every Sprint. This is often the right compromise between the effort required on the part of the Product Owner to write small PBIs and the risks mentioned above.

When a team is having trouble starting and finishing several Product Backlog Items in a single Sprint, there are usually two opportunities for improvement. In both cases the Development Team and the Product Owner work together to improve the items. This Product Backlog Refinement collaboration is one of the most technically demanding aspects of the Product Owner’s role. It is essential that Product Owners learn and practice how to write and how to split Product Backlog Items (PBI) effectively so that the Product Backlog communicates the Product Vision clearly to the Scrum Team.

Sometimes a Product Backlog contains items that actually represent overall product characteristics rather than features or functions. For example, a Scrum Team might be developing the English version of the product, but somewhere on the backlog is an item that says “Translate into French and Chinese.” The language of the product is actually an overall product characteristic. These types of items can often be identified because the amount of effort to complete them depends on the size and complexity of the product. These product characteristics should not appear as Product Backlog Items at all. Instead, they should become part of the team’s Definition of “Done”. This means, essentially, that the product characteristics are built into the product every Sprint. To continue with the earlier example, this means that the Scrum Team would create the English, French and Chinese versions of the product right from the first Sprint. Each Sprint that adds functionality to the product would require updating and adding new translations from English to French and Chinese. The Product Owner, the Scrum Team and the other stakeholders work to ensure that each Sprint results in Potentially Releasable Product Increments, and therefore these non-functional product characteristics should be identified as early as possible in the development effort. However, if new product characteristics are discovered later on, after the product already has many features built, the Product Owner must decide on how to order the Product Backlog Items to allow the team to “catch up”. Again, using the same example, imagine that the Product Owner realizes that the product also needs to be translated into Arabic. The Product Owner then might write a number of Product Backlog Items to prioritize the translation of various features or feature sets of the product, rather than just a single item for the whole translation.

PBIs near the top of the Product Backlog are likely to be implemented by the Scrum Team in the upcoming Sprint or Sprints. Therefore the Product Owner spends the necessary time with stakeholders and Scrum Team to ensure the PBIs are well understood and ready for implementation; that is, the Scrum Team expresses confidence that the PBI can be achieved within a single Sprint and they understand the problem-to-be-solved or functionality-to-be-implemented well enough that they can get started. Note: “understand enough to get started” does not mean that all details are known. Often, a single keyword or short phrase is enough information that a Scrum Team can confidently get started. The INVEST acronym is a guide to writing clear and effective Product Backlog Items:

1. Independent of each other. That is, each PBI can be implemented independently of one another and represents functionality through the system which, in itself, is complete.
2. Negotiable. That is, design decisions and implementation details are not prescribed in the PBI. Rather, the implementation – the “how” — is negotiable.
3. Valuable to the customer. Each PBI must add value to the product and provide a return on the customer’s investment.
4. Estimable. If business stakeholders cannot estimate the relative value or the Development Team cannot estimate the relative effort required to implement the PBI, these are signs that the PBI is not provide enough clarity about the desired functionality or usage.
5. Small enough that the Scrum Development Team members have high confidence they can implement the item completely within a single Sprint.
6. Testable — the team and stakeholders clearly foresee ways they can test both the functionality and benefit.

Product Backlog Items that are features or functions are often initially added to the backlog such that the effort to complete them as described would be much larger than a single Sprint. In this case, the team has the opportunity to split items into smaller units of work that still maintain business, customer or user value. Eventually, most large Product Backlog Items are split into many “micro-features” before they actually get implemented. There are many different techniques for splitting backlog items. A search online will find numerous lists and descriptions of these techniques. The five most common techniques are briefly described here:

1. Split by “and”. Example: “As a Hiring Manager and a Recruiter I can list a new open position…” can be split into “As a Hiring Manager…” and “As a Recruiter…”.
2. Split by “or”. Example: “As a Job Seeker, I can upload my resume in MS Word or PDF or OpenDocument formats…” can be split into “… I can upload my MS Word resume…” and “… I can upload my PDF resume…” and “… I can upload my OpenDocument resume…”.
3. Split by process step. Example: “As a Job Seeker, I can apply for a job…” can be split into “… I can select a job listing to apply for…” and “… I can choose which version of my resume to submit with my application…” and “… I can write a custom cover letter to include with my application…” and “… I can include references from my network to include….” etc.
4. Split by user options. Example: “As a Hiring Manager I can create an account…” can be split into “… I can create a pay-as-you-go account…” and “… I can create a basic monthly subscription account….” and “… I can create a sub-account as part of my enterprise subscription…” etc.
5. Split by business logic. Example: “As a Job Seeker I can log in to my account…” can be split into “… I can successfully log into my account with correct username and password…” and “… I can fail to log into my account with incorrect password…” and “As a Hacker, I can get my IP address blocked when I attempt malicious logins…”.

Please be sure to never split backlog items into technical components or layers as the work resulting from one of these items will not result in a Potentially Releasable Product Increment.

Further information about writing and splitting user stories can be found at agileadvice.com/tag/splitting

Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.

— The Scrum Guide

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…