The Rules of Scrum: All PBIs are related to a single product (or system)

Scrum Teams work on one product at a time.  The Product Backlog represents all of the work that needs to be done on that single product.  The complete list of Product Backlog Items represents the goal of delivering all of the presently known features of a product.  Multiple teams working on a single product, therefore, work from a single, shared Product Backlog.  Working on Product Backlog Items from multiple Products causes the team to task switch into a different business domain and possibly into a different technical domain.  Task switching creates wasted mental effort and therefore causes a team to be less effective than they could otherwise be.  Having a single product to work on creates focus in both the business and technical domains.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

4 thoughts on “The Rules of Scrum: All PBIs are related to a single product (or system)”

  1. This one is of particular interest because I think it’s important to understand what is defined as a product.

    So my question goes out to others at large to see what the common thought may be.

    I will provide a scenario personal to my area:

    I work within the Corporate System HR/Payroll area as an Application Architect. We provide service and support to the Oracle Enterprise Suite, specifically the HR and Payroll Oracle Application modules. We provide that maintenance support as well development needs to service integration feeds to various systems internal/external to Humana.

    We are currently applying Agile as a SCRUM team that supports the system as a whole. Based upon this article, that would seem to imply that the Oracle Enterprise Suite and those pieces we work on… are all the single *Product* ..the Enterprise Suite and related integrations. If this is true, then it would seem to comply to with assertion that “Scrum Teams work on one product at a time”.

    Let’s break this down a bit more. That overall *Product* actually consists of :

    – Talent Acquisition System
    – 401K
    – Voluntary Benefits
    – Acquisition Onboarding
    – Manager Self Service
    – HR Self Service
    – Timekeeping
    – Salary Planning and Calibration

    If we were to say that these are the true *Products*, then we would be in direct contrast to the assertion. I say this because more often than not, we have 1 or 2 people working on a given piece, but manage the the overall environment as a single SCRUM Team.

    Have we applied Agile incorrectly within our environment ?

    Am I misunderstanding what the definition of *Product* is ?

    Is there anyone else that deals with an umbrella application suite, with supporting modules underneath, which is further extended by individual processes that sometimes are dependent on other processes, and other times completely stand alone.

    **Thoughts and comments are very much welcomed.

    1. Hi Barry, thanks for offering a great set of questions! I won’t answer everything, but I wanted to challenge the idea that your team is doing product development. Based on what you described, I believe that you are doing IT system development/support and that is not the “sweet spot” for Scrum. Product development usually implies customers that are paying directly for the product in question and that there is more than one potential purchaser (re-usable across multiple customers). In IT system development, you usually only have a single customer (the organization you are working within) and they are often not the direct customer in that they don’t use their own budget to pay for the product, instead payment comes from an IT budget. These differences are important to consider when you are choosing an Agile method. Scrum probably works well for you, but you may find that other Agile methods such as Extreme Programming, OpenAgile or Kanban work even better since they are not so focused on product development.

      As for the question about the different aspects of your system, I think it is fine to have a single Agile team focused on all of them or just specific parts.

    1. No problem, happy to help! Feel free to comment here if you have any further questions, and definitely check out our other posts here. There’s lots in the archives about different Agile methods that might help.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.