All Scrum Team Members, including the ScrumMaster and Product Owner, should understand the high-level technical aspects of the product that is being built. As well, that understanding should be solid enough, that it can be communicated to other people. This understanding helps the team members in many situations dealing with each other and with stakeholders. Understanding the structure of the system is an aspect of Transparency. This is essential for maintaining overall quality of the product. Development in one part of the product or system should never cause problems for any other part of the product or system. If team members do not know their product in this way, it can cause significant problems in communication and in how Product Backlog Items are implemented.
All PBIs completed by the team should be “potentially shippable” increments of complete value. 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 shipping product needs to be completed on all individual PBIs. Creating slices through our system allows the Scrum team to deliver value each and every Sprint and also allows for the Product Owner to change direction to a new feature if it is more valuable for a future Sprint. What happens if we don’t create and complete PBIs that are slices through the system? We risk falling into a pattern of not having a potentially shippable product each Sprint, and, even worse, we may regress into a waterfall type process that produces nothing of value to the customer until the end of the project.
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.