Scrum framework : Strategies to break down Product Backlog Items (PBIs)

Strategies to break down Product Backlog Items in Scrum :

• See the original here.
• 10 best strategies for breaking down the PBIs :
  • Strategy 1 : Breaking down by workflow steps
  • Strategy 2 : Breaking down by business rules
  • Strategy 3 : Breaking down by happy / unhappy flow
  • Strategy 4 : Breaking down by input options / platform
  • Strategy 5 : Breaking down by data types or parameters
  • Strategy 6 : Breaking down by operations
  • Strategy 7 : Breaking down by test scenarios / test case
  • Strategy 8 : Breaking down by roles
  • Strategy 9 : Breaking down by ‘optimize now’ vs ‘optimize later’
  • Strategy 10 : Breaking down by browser compatibility
• Other possible 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 PBI.
      • Mapping out acceptance criteria for a PBI requires similar strategies like 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 web service (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.

When is a Product Backlog Item small enough ?

• There is no clear-cut rule on how small a PBI should ideally be.
  • This greatly depends on the length of the Sprints, the nature of the application, and the size and experience of the Scrum Team.
  • It often takes a Scrum Team several Sprints to figure out the sweet spot.
• My own experience is that Scrum Teams should strive to add at least between 5 and 8 items to a one-week Sprint (one per day).
  • They don’t have to be of equal size, but they shouldn’t be too big on their own.
  • This also gives a clear goal to the refinement process of upcoming work.

On potential concerns from the Scrum Team

• Concerns :
  • There are some concerns that I often hear from Scrum Teams when they’re trying to break down PBI’s.
• First concern
  • The first is that Scrum Teams are worried about the reduced business value of smaller items.
    • Of course, smaller items will have reduced business value compared to the larger item.
    • But the primary purpose of breaking down functionality is to reduce Risk, increase flow and increase the amount of working functionality that can be reviewed at the end of every Sprint.
    • The alternative is to keep working with very large chunks of functionality, with all the afore mentioned consequences and Risks.
• Second concern
  • Another concern is that breaking down functionality results in more work.
    • For a Scrum Team, it’s often easier and faster to keep working on a piece of functionality until it’s completely done.
    • Revisiting bits and pieces throughout the Sprints feel wasteful.
    • Although this may be true to some extent, there is good reason to still do this.
    • In Scrum, we implement a process that is designed to continuously review and test our work and adjust according to the feedback we get.
    • So, the functionality that you may have in mind now may be very different from what will actually be implemented when we use Scrum.
    • Although it may be tempting to keep working on a piece of functionality, there is a good chance that you are wasting your time on functionality that will be changed further down the road (based on feedback from users, stakeholders, etc).
• Third concern
  • A final concern is that many Scrum Teams do not immediately ‘get’ how to break down functionality.
    • It is not uncommon to run into some resistance as a result.
    • This is understandable; trying out new things is difficult because it makes people feel vulnerable.
    • The best way to deal with this is to persist and gently coach the Scrum Team by helping them break down their PBI’s.

Wrapping up

• Wrapping up (emballage, emballer) the PBIs
  • Small is beautiful
    • In this post, I have emphasized the importance of continuously breaking down large PBI’s into smaller ones.
    • A sprint should preferably consist of many small items instead of only a few large ones.
  • Risk
    • The fewer (and larger) the items in a Sprint are, the larger the Risk of failing the Sprint.
• Strategy
  • I have offered 10 well-known strategies used by experienced Scrum Teams that may be of use to your Team.
  • Good luck!

Cheatsheet

• Download the cheatsheet or download a fully prepared string to refine a tough and very unclear item with stakeholders.

Versioning

• Created on 01/03, 2023.
• Updated : 01/03, 2023.