Scrum Rules: Product Backlog Items Are Features or Functions

All PBIs completed by the team should be “potentially releasable” increments of valuable functionality i.e. working features or functions. In order to do this, they must touch all the layers and components of the product so that the functionality produced is truly complete, not just a prototype — a “slice” through the system.

In other words, all of the work that is required for releasing product needs to be addressed while working on any individual PBI. Writing PBIs to represent slices through the system allows the Scrum team to deliver value every Sprint and also allows the Product Owner to re-order the Product Backlog flexibly and without risk of leaving undone work. What happens if we don’t create and complete PBIs that are slices through the system? The result is a Product Backlog with many dependencies between items which then must be delivered sequentially before complete features or functionality can be released to end users (e.g. “waterfall”).

The single most important practice for enabling a Scrum Team to follow this rule is the principle of Collective Code Ownership: every team member has access and authorization to change every line of code throughout the whole system and any dependencies. This enables a team to take a Product Backlog Item and change anything anywhere in the system in order to implement the desired functionality. Collective Code Ownership requires that the Development Team members have the authority (regardless of skill set) and support required to confidently adjust the system as necessary. This often requires that every Development Team member is given access to the source control & configuration management systems. Team members may need to be trained on the use of the source control and/or build tools. This access should include all components and layers in a system from the user interface, through business logic, all the way to the database schema, stored procedures, test environments, and deployment scripts. When Collective Code Ownership is in place, organizations with multiple teams accessing the same code base may also implement a “shepherding” system where senior technical staff have informal responsibility to ensure that the code base has a clean design and is architecturally sound.

If there is just a single team accessing a code base, then the informal internal communication is usually sufficient to ensure the quality of the code base. The application of this rule also requires the adoption of many other Agile engineering practices including, most notably, Test-Driven Development, Mob or Pair-Programming, Continuous Integration, and Refactoring.

Only then can fully working features truly be ‘released each sprint’.

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…