One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses. We are delivering some of them ourselves, but we are also bring in outside experts for others.
Here is the course list at a high level:
- a 1-day “Advanced ScrumMaster” course
- a 1-day “Advanced Product Owner” course
- a 1-day “Managing for Success” course
- a 1-day “Enterprise Agile” course
- a 2-day “Agile Engineering Practices” course
- a 2-day “Agile Coach Training” course
Our schedule for these events will be finalized in the next few weeks. If you are interested in any of these courses, please pre-register here. Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.
Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information
Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams. Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram. If you give someone a map, they tend to assume that all of the exploring has already been done. If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored. Maps and diagrams do serve a purpose. They are useful. What’s important to always keep in mind is that they should not be regarded as definitive but rather as one contribution to a body of knowledge that can and should grow.
Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created. One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him. All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum. So, I decided to create my own.
This is the first increment. I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.
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.
Solving technical problems is the job of the product developers on the Scrum Team, not the Product Owner. The Product Owner is responsible for the product from a business and user perspective and has authority over the team only in this limited realm. By overstepping the bounds of authority in this way, the Product Owner becomes an obstacle for the team by reducing its ability to self-organize. A Product Owner who is part of a team that has reached a high-performance state may be able to safely make technical suggestions, but should always be careful not to push the team to accept those suggestions.
The Product Owner’s main responsibility is to maintain the Product Backlog through direct communication with the users and stakeholders. To do this well it will take most of his time and effort to be effective. Hands-on technical is done by the Team Members not the Product Owner since this is not the Product Owner’s strength or area of expertise. If the Product Owner refrains from doing the hands-on technical work, then he is able to provide the vision and share the “what” that the team needs to accomplish. If not, he will be bogged down by the tasks and lose the time and ability to provide product guidance and connect with the stakeholders.
The Product Owner needs to be highly available to the Scrum Team. If the Scrum Team has a question about a Product Backlog Item, then the Product Owner should be able to respond within minutes to that question. Responding this quickly ensures that the Team is building the Product in a way that best satisfies the Product Owner. In particular, it helps to avoid surprises about basic aspects of the Product during the Sprint Review Meeting that then lead to wasteful changes or re-work. If the Product Owner does not have this level of availability, it may not cause any immediate problems, particularly if there are other team members who know the business and the product well. However, since Scrum holds the Product Owner accountable for what is built, it is often better for the Team to check its assumptions with the Product Owner.
The Product Owner is responsible for the Return on Investment (ROI) of the Product. In order to manage that responsibility, the Product Owner needs to estimate how much financial benefit the Product Backlog Items for a specific Sprint will generate, and compare that to the effort of one Sprint’s worth of the Scrum Team’s labor. This calculation then allows the Product Owner to decide if a given Sprint is worth doing or if the Scrum Team should turn its attention to other work… possibly even a different product. If the Product Owner has these estimates, then it is possible for the Product Owner to maximize the ROI of the Scrum Team. When these estimates are missing, it is difficult to ensure that the Scrum Team is working on the best possible PBIs. In the worst case, the Product Owner will spend the Team’s time working on very low ROI items and cause substantial problems for the business.
The Product Owner has the sole authority on putting the work of the Scrum Team at the end of a Sprint into the hands of users. This means that at the end of a Sprint, after the Sprint Review has occurred, the Product Owner considers the state of the Product (features, quality, performance, etc.) and the state of the business/market, and decides if the product should be sent out. In an IT or web environment, this means deployment. For other types of software this might be live updates or sending out DVDs to customers. There should be no other individuals who have the authority to do extra releases without the Product Owners approval, nor should there be anyone who can stop a release from going out if the Product Owner makes that decision. If the Product Owner has this authority, it can create a high level of efficiency in addressing the needs of the business or the needs of the market. If the Product Owner does not have this authority, then it undermines their authority over the ordering of the Product Backlog (since that ordering becomes meaningless) and it undermines the broader organization’s ability to hold the Product Owner accountable for results.
The Product Owner needs to be in contact with all those that are invested in the work of the team (aka stakeholders). These stakeholders have information on the marketplace, the users’ needs, and the business needs. The Product Owner must be able to communicate with each of these individuals whenever the need arises. If this is possible, the entire Scrum Team will have the most up to date information that will aid them in their execution of the product. If not, the team will have to wait for information and/or guess which will cause confusion, blame, distrust, and unhappy customers.
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 Product Owner duties make up a full-time job on a Scrum Team. The Product Owner should not be a manager, a developer or have any other partial duties outside the role of Product Owner. This focus allows a Product Owner to complete their duties with complete focus and commitment to the success of the Product. Of course, in the creation of a Product and its vision, there are many things that need to be done with customers, users and other stakeholders, not just working with the Scrum Team directly. If the Product Owner has other duties outside of Product Owner duties, then one or more of the Product Owner duties are compromised, the Product Owner job is not being done and the team suffers. An individual who feels unable to serve as a full-time Product Owner should not accept this position or should work with their management to enable it to become a full-time position.