The Product burndown chart tracks the amount of work remaining in the Product Backlog Sprint-by-Sprint. This burndown chart is updated every Sprint and is visible to the Scrum Team and its stakeholders. This activity is part of the Product Owners duty to facilitate transparency around value delivered over time. The Product Owner is responsible for making the overall progress of the work visible to the Scrum Team and other stakeholders. This activity is part of the Product Owners job to satisfy stakeholders as it allows them to easily see how the Scrum Team is trending on planned deliverables. This information allows the team and the Product Owner to discuss any necessary adjustments to the team’s plans for the upcoming Sprints in a timely fashion. What happens if the Product Owner fails to create and/or maintain the team’s Product burndown chart? Most likely we will be unable to see if the team is on track, late or early in its delivery of value. In a traditional waterfall approach we would find out this information near the end of the project which is much too late. Also, without regular updates on the trend of the team it is highly probable that stakeholders and/or team members may slip back into an individualistic approach to work instead a team based approach.
The Product Owner has complete authority over the ordering of the Product Backlog. However, it is strongly recommended that the Product Owner put all known defects at the top of the Product Backlog so that the Team fixes them in the very next Sprint. By defects is meant features of functions of the system that have been built by the Team in previous Sprints where those features or functions do not behave according to the expectations of the Product Owner and where such mis-behavior is exposed to users of the system. There may be other quality problems with a system which are not categorized as defects (e.g. duplicated code). This prioritization of defects generally results in extremely high levels of quality in a system and a long-term reduction in costs for the system (total cost of the system) by making future features easier to add, and reducing effort spent on maintenance and support. Failing to put defects on the top of the Product Backlog generally leads to decreasing overall quality and in particular can severely damage the morale of a Scrum Team thus preventing them from getting into a high-performance state.
The Product Owner is involved with the other Team Members throughout the Sprint, but after the Sprint Planning meeting is completed, the Product Owner cannot add to the scope of the work being done during the Sprint. New Product Backlog Items, no matter how high their priority, must be put onto the Product Backlog for the team to look at in the next Sprint. This restriction is meant to allow the team to truly be focused and committed to the work of the Sprint and to allow them to make commitments and learn to keep them, thereby building trust. The Product Owner can, of course, collaborate on the details of the PBIs the team has chosen for the Sprint. If the Product Owner does indeed force a team to take on extra work during the Sprint, it breaks the focus of the team and can lead to the team’s failure to complete the work they planned.
The Product Owner controls the order of the items in the Product Backlog, but not how many are done each Sprint. Instead, the team decides how many to do. This decision is made in Sprint Planning and, of course, should be made in collaboration with the Product Owner, but ultimately the Product Owner must let the team freely decide how many items are planned. This freedom allows the team to be truly motivated and committed to the work as well as being collectively accountable for getting that work done. If the Product Owner forces a team to take on more work than it feels is within its capacity, then that dis-empowers the team, moves accountability for getting work done to the Product Owner, and completely dis-ables the team from getting to a high-performance state.
The Product Owner is responsible for maintaining the Product Backlog. This includes its ordering in terms of value and effort, its clarity, and identification of what acceptance criteria apply to each Product Backlog Item. It is also very important for the Product Backlog to be ready for each Sprint Planning Meeting so that the team can select the Items for the current Sprint and break those down into tasks. If this is done, the team is able to create an effective Sprint Backlog where it can volunteer for tasks and achieve quick wins each day. If not, the team will likely take on the work of refining the Product Backlog during the Sprint Planning Meeting which is wasteful and not focused. Having a ready Product Backlog helps the team focus during its meetings and ask relevant questions to the Product Owner.
The Product Owner is responsible for ensuring that the Product Backlog Items reflect and contribute to the vision of the product being built by the Scrum Team. Therefore, the Product Owner needs the authority to reject any suggestions for features, functionality or fit and finish that do not move the product towards that vision. This authority must be based on both the depth of knowledge of the Product Owner as well as formal responsibility granted by the organization. A Product Owner that does not have this authority to veto may nevertheless be able to accomplish the same thing by putting any unwelcome ideas at the very end of the Product Backlog based on authority to order the Product Backlog. The lack of this authority to veto can lead to a product with no integrity of vision, an erosion of the Product Owner’s authority to order the Product Backlog, and ultimately an erosion of the critical separation of powers between the Product Owner and the rest of the Scrum Team (the Product Owner with authority over “what to build” and the rest of the team with authority over “how to build it”).
The Product Owner’s job is to be the customer or the customer proxy. He needs to know the most current information about the product and the business that the team is working in. If this is the case, then the Product Owner is able to make relevant choices about the product and will be able to answer the questions of the team. If this is not the case, then he will have to find someone else for the answers (which will cause waste), make up the answers (which will likely guide the team in the wrong direction), or fail to give the team what they need.
The Sprint Review is a key meeting for the team to improve the product. There are three main purposes of the Sprint Review: inspect how the last Sprint went with regards to the product; identify the items that are complete and order any potential changes; and, integrate those changes into the Product Backlog. This meeting aids the team in inspecting and adapting the entire product increment and how the team is progressing towards any deadlines. The Sprint Review is a check point that helps the Scrum Team to know the product’s current state, compare to its desired state, identify gaps, and take the needed steps to improve. This meeting is also where the Product Owner challenges the Scrum Team to look at the product clearly (it’s not just for the stakeholders!). When a Scrum Team refrains from having and participating in this essential meeting, the is team is likely to become a Scrum Team in name only without any of the far reaching benefits that many other Scrum Teams have experienced. A demonstration of the Product Backlog Items completed in the Sprint is often a part of this meeting.
The Product Owner has the most recent and important information about the value and cost of the product being delivered. This information can greatly serve the team by allowing them to understand the product’s current state and how this affect where they will be going in terms of the vision of the product. If the Product Owner is able to carry this out then the team will have relevant information that will aid them in their decisions and execution of the product. If this is not carried out then the team will be in the dark – they will make poor decisions and struggle with the feedback given by the stakeholders since they have no transparency into the reality of the product.
Over the past six months we have been working hard on launching a new product: The Scrum Team Assessment. This tool delivers to you a valuable report full of practical advice on how your team can get better at Scrum… and deliver better results! It’s like an automated Scrum coach. All your team members will fill in a comprehensive survey, we collect the results, generate a report – and then we personally review it – and send it back to you.
As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team. It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI. One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”. If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software. If the Team Members choose their own scope they may do much less than is needed or much more than is required. There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.
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 Scrum Team Members, including the ScrumMaster and Product Owner, should understand the high-level business 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 purpose of the system is an aspect of both Focus and Transparency. This is essential for maintaining overall quality of the product. Development should always be done in a way that moves the system towards fulfillment of its intended purpose. 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. Finally, and perhaps most importantly, understanding the overall purpose of work is critical for a team to become a high-performance team. Without knowledge of this purpose, a high-performance team is impossible.
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.