Scrum relies on the truthfulness of Team Members to allow for transparency about the internal quality of the product. Internal quality is primarily related to the technical aspects of the product: its design, its architecture, lack of duplication in the code, and the level of coverage of the product with automated tests. Scrum relies on the professionalism of the Team Members for the proper implementation of this rule. Being upfront, transparent, and truthful about the internal quality of the product allows for the Product Owner to understand how much time and effort the Team will allocate to improving the internal quality of the product and how much will be allocated for new features. This also gives the ScrumMaster an opportunity to connect with stakeholders who may be able to help remove technical debt and waste that is continuing to exist. If Team Members are not truthful about the internal quality of the product, over time the system will become more cumbersome, more complex, and more painful to improve. This will also lead to a culture of hiding problems, which diametrically opposite to the intended use of Scrum: to uncover problems and allow us to solve them. Another downside is that morale will begin to decrease as Team Members care less about the quality of their work. This, of course, will ultimately lead to external quality problems that result in customers being unhappy and looking for someone else to work with.
Scrum is an Agile process framework that is optimized for product development. The rules of Scrum are fine-tuned after decades of use to help product development teams become hyper-productive and to maximize business value. If you use Scrum for product development, then you are applying it to the right problem. If you use Scrum for some other type of work (e.g. general project management) then you are mis-applying Scrum and it probably won’t give you the ideal results. Scrum is not simply a collection of best practices. Therefore, if you are using Scrum by picking and choosing some of its pieces, it is likely that you are using a sub-optimal approach to product development. In this way, Scrum is like a tool rather than a toolbox with many tools. When you take a hammer out of a toolbox, you don’t pull the head off and start pounding nails without the handle. Likewise, if you only use some parts of Scrum, you are missing the benefits of using Scrum as a tool. As a Scrum Team Member, you should know the purpose of Scrum and be aware of applying it correctly to the right problems.
The Product Backlog is a constantly changing artifact, owned by the Product Owner. Stakeholders need real-time visibility into the current state of the Product. Stakeholders should be able to discuss the state of the Product Backlog with the Product Owner at any time, make recommendations and requests. Any change resulting from the request of any stakeholder(s) must be visible in real-time to all other stakeholders. One of the greatest benefits of a highly visible Product Backlog is that it becomes a conversational space for key stakeholders and many others that are connected to or interested in the work of the Scrum team. Of course, a visible Product Backlog also upholds the Scrum value of transparency which is essential for long-term success with Scrum. What if my Product Backlog is not easily visible to every stakeholder? Stakeholders will become disengaged from the work of the Scrum Team, and will forget to give support and/or offer insights into the work. If the Product Backlog is managed in an electronic tool that requires people to login and/or go into a special space that has restricted access then they are much less likely to view it regularly.
The Product Backlog is a list of potential work to be done for future Sprints. This list is most vibrant when as many people as possible contribute to it. Those directly connected (stakeholders such as the Team Members, users of the systems, etc) have a stake in the product’s growth so they also have plenty of ideas that may benefit its value. Adding a Product Backlog Item (PBI) is like brainstorming where all ideas are welcome. Then it is the responsibility of the Product Owner through conversations with others to order the list based on the most value for the least effort (and sometimes to reject PBIs if they are too outside the product vision). If the creation of PBIs is limited to just a few individuals, or even just the Product Owner alone, it is likely that many great ideas will not surface and will be lost. Also by having all stakeholders contribute PBIs, the Product Owner builds collective ownership in the work of the Scrum Team which helps the team overcome obstacles and become supported by a larger group.
Product Backlog Items closest to the top of the Product Backlog should be small enough for the team to be able to complete at least one potentially shippable slice of the product in the next Sprint. As well, they should be ready for the Sprint Planning meeting so that the team can plan its work for the Sprint. To be ready for the Sprint Planning Meeting, each PBI must be estimated. Generally speaking, Product Backlog Items at the top of the Product Backlog are clearer and more detailed than lower ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that at least one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting. Having too many items in the Product Backlog “ready” for the team is considered wasteful over-planning, although generally the top ten items should be in this “ready” state. The value of having a refined Product Backlog before the Spring Planning Meeting is that it enables the Scrum team to focus on the purpose of the Sprint Planning Meeting which is to answer these questions: What will be delivered in the Increment resulting from the upcoming Sprint and how will the work needed to deliver the Increment be achieved? Essentially, what is the Spring goal and what are the tasks needed to complete the goal? Without a ready Product Backlog, the purpose of the Sprint Planning Meeting is difficult to achieve.
One of the key benefits of the using Scrum is that it allows the team to quickly identify defects and obstacles. Now that the team has made these known, the team has the ability to remove and fix these defects. What is the value of identifying problems in the product when nothing is done to repair them? The team will become much faster if it can improve the quality on its own by removing known defects and making the software better. Then the team will be able to take on more audacious goals instead of being weighed down by quality problems. Moving known defects to the top of the Product Backlog places quality work as a central goal for the team to achieve which directly improves the product, makes customers and users of the software much happier and invigorates the team to continue to become more effective. Placing known defects away from the top of the Product Backlog causes morale challenges, acceptance by the team of poor quality work and creates an atmosphere of apathy. These are likely to cause a failure by the Scrum Team to deliver on its goals.
Product Backlog Items are brief descriptions of a feature or function. Usually they are short enough that they could be hand-written on a small note card. This brevity is meant to be just enough information so that the Product Owner and the team can use the PBIs as invitations to conversations. The resulting conversation (ongoing, evolving and involving the whole team and stakeholders) and the shared understanding that comes from that conversation is where the real value of the PBI resides. Part of the conversation occurs when the Product Owner initially writes the PBI so that the team can estimate the effort of building it. Part of the conversation is the actual work being done during a Sprint. Another part of the conversation is during the Sprint Review when stakeholders see the results of the team building the PBIs. If one creates PBIs as detailed specifications then we are essentially handcuffing the team into a set path and a prescriptive solution. The reason we hire qualified people onto our Scrum Team is for their knowledge, experience, and problem solving abilities. If we lock them into a set path, then we are literally turning them into cogs in a machine to spit out specific code. PBIs that are invitations to conversations allow them the flexibility to figure out how to solve the problem by engaging in a conversation on what is needed.
Product Backlog Items (PBIs) that are at the top of the Product Backlog (in other words, those which are to be done next), need to be small enough that the Scrum Team can comfortably complete all the work for them within a single Sprint. The Product Owner should be spending a little time every Sprint to split “large” PBIs into small PBIs. The Product Owner relies on the team to estimate if they are small enough. If the PBIs are not small enough then large problems can arise. Probably the most serious problem is that the Scrum Team may be unable to start and finish PBIs in a single Sprint which can seriously hinder the “inspect and adapt” process due to Sprint results that cannot be demonstrated in the Sprint Review. Almost as bad, incomplete work can leave a mess in the system if the Product Owner for some reason decides to change priorities and not complete work started in a previous Sprint. Finally, incomplete work dis-empowers the Product Owner from being able to make a business-based decision to ship or deploy the Team’s work at the end of the Sprint. A smaller problem that can arise from PBIs that are large is that the Team may not be able to fill their Sprint as effectively. One way to think about this is the difference in how much empty space there is in a cup filled with large pebbles versus a cup filled with sand. The rule of thumb is that PBIs should be small enough that between five and ten fit into every Sprint. This is often the right compromise between the effort required on the part of the Product Owner to write small PBIs and the risks mentioned above.
The User Story is a tool developed with Extreme Programming that is almost universally accepted as part of Scrum. The User Story format is an effective way of communicating end user value to the Scrum Team. The first blank is a user (a person, not a system), the second blank is the action of the story (unique), and the third blank is the benefit (for any stakeholder, and outside the system). A User Story is made up of three “C’s”: Card, Conversation and Confirmation. The Card is the written version of the story (usually a physical card on the wall). It is considered to be an “invitation to a conversation”. The Conversation is where the real value resides and potentially involves all stakeholders. The Conversation can cause changes to the Card. Confirmation is the acceptance criteria that, when tested against, confirms the valuable result of the story. A User Story is an extremely effective way of creating light and conversational PBIs – this is why many Scrum teams use them. Another way to view User Stories is that it tells any reader the “who”, the “what”, and the “why” – who cares about this, what is the need/action, and why does the person want this. This is just enough information to make sure that an effective conversation occurs.
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.
Product Backlog Items are ordered into a sequence in the Product Backlog in such a way that the Product Owner is able to maximize the return on investment (ROI) in the team. The very first PBI in the Product Backlog should be the one with the highest expected value considering the effort to build the PBI. There are many ways to calculate this expected value including Return on Investment (ROI), Net Income After Taxes (NIAT), Net Present Value (NPV), etc. The Scrum Team members should be free to ask why one PBI is prioritized higher than another, and the Product Owner should be able to give a reasonable answer. Since the entire Scrum Team is accountable for its work, it is in the best interest of all members of the team to use expected value, so that both the Scrum team and the customer will be committed to the work that is currently being worked on and the upcoming work in the future Sprints. If we don’t order the PBIs by expected value, then the Product Owner is likely to prioritize them based on dates, feelings, urgency, or other less valuable methods. These other prioritization methods will diminish the trust of the team in the Product Owner and may lead to morale problems.
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.
The Product Backlog must be ordered so that the Product Backlog Items can be thought of as a sequence of valuable pieces of software to be built. There is always a first item (not two or three first items) then a next item, etc. until you get to the end of the list. The list is “ordered” so that there is a strict sequence with exactly one Product Backlog Item at each position in the list. The sequence is determined by the Product Owner and is used during Sprint Planning to determine what the team will do. This ordering helps to create a strong discipline around choosing what should be done next. It also encourages the Product Owner and the Scrum Team to think about how to break dependencies. If two or more Product Backlog Items have the same position in the Product Backlog, it means that the Product Owner has not prepared for the Sprint Planning meeting and the team may be less effective in that meeting. Having two or more Product Backlog Items in the same position in the Product Backlog is, in fact, a slippery slope that can lead to very poor prioritization, and even sub-optimal results from the team. Minor or occasional deviations from this rule will have a low impact, but categorizing Product Backlog Items into a small set of priority levels (e.g. MoSCoW prioritization – http://en.wikipedia.org/wiki/MoSCoW_Method) will reduce the effectiveness of the Sprint Planning Meeting dramatically.
Since the Scrum Team only includes three roles: ScrumMaster, Product Owner, and the Team Members, there is no need to have other people on the team. Each of the Scrum roles has a specific function that requires their full-time attention. These roles are all the roles necessary to accomplish the creation of a high-performance Scrum Team. Adding people to the team who have any other roles will hinder the team from engaging in the requisite amount of self-organizing behaviour.