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.
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.
There are three roles on a Scrum Team, no more and no less. These roles are: ScrumMaster, Product Owner, and the Team Members. It is critical to have all three roles present on the Scrum Team to get all needed responsibilities taken care of in an effective way. The Product Owner is responsible for the product and how the team connects with that product. The ScrumMaster is responsible for improving the use of Scrum in the organization and team, as well as removing any obstacles that slow the team down. The Team Members are responsible for getting the work done by self-organizing and finding ways to improve their own process and work. Without one of these key roles, the team would be missing a key focus and job. As well, Scrum specifically disallows any other roles on the Scrum Team. A person who has an official role of Tester cannot be on a Scrum Team. However, the same person, if given the official role of Team Member can be on a Scrum Team. If people have their official titles, performance evaluations etc. done in their traditional roles, it hinders self-organizing and causes conflicts of interest. A team is not a Scrum Team until those old roles are eliminated.
A very effective learning that has come out of many fields of research is that we function well in small groups, specifically groups that range from five to seven people in total. Scrum allows for a slight expansion of that range up to eleven people. This allows for enough people to be together to discuss issues and solve complex software problems with a diversity of skills and experience. As well as avoiding the problem of having too many people that the lines of communication become overwhelming. If the Scrum Team is only four people, then that means that you only have two people doing the tasks in the Sprint Backlog (since the others are the ScrumMaster and the Product Owner). If the team is thirteen or more people then trying to discuss issues, having a focused Daily Scrum meeting, and even building an effective Scrum Team becomes that much harder. The larger the team, the longer it takes to get to a high-performance state.
The Product Owner brings Product Backlog Items to the Scrum Team to estimate their effort (cost). In order to create the right environment of safety and accountability, no Product Backlog Item is estimated by a single member of the Scrum Team, or even a subset of the team membership. By having all the members of the Scrum Team participate in the estimation work for every Product Backlog item, it becomes impossible to blame a single Team Member for a poor estimate. At a practical level, it is should be very rare that a single Product Backlog Item is fully implemented by a single Team Member. Therefore, estimates should consider the collective effort of the Scrum Team, and this can only be determined by having all the Team Members participate in the estimation work. If the team delegates estimation to a single person, or if one person dominates the estimation work, the other Team Members will not have ownership of the estimates and will be able to deny accountability. The pressure on the team from collective estimation encourages teamwork, cross-training and these behaviours in turn promote the development of a high-performance team.
The Scrum Team plans their work in the Sprint Planning meeting and that planned scope (Product Backlog Items) is meant to be respected… it is a commitment by the team. In exchange for that commitment, the rest of the organization commits to leaving the team alone to focus on its work. Focus and commitment are both important values of Scrum. Any interruption to any individual Team Member except the ScrumMaster and Product Owner is considered a cause for relieving the Team of its commitment. This rule of Scrum is designed to put pressure on the organization to leave the team to focus on the most valuable work. If the organization allows interruptions to the team’s work during the Sprint, then the team will not meet its commitments and this will diminish trust between the team and its stakeholders. That lack of trust will lead to onerous control mechanisms that reduce the team’s ability to self-organize which, in turn, will prevent the team from becoming a high-performance team.
The Daily Scrum meeting is a critical method for creating transparency between Team Members. Every day, each Team Member in turn answers the three questions of the Daily Scrum: what tasks have I completed, what tasks will I complete before the next Daily Scrum, and what obstacles do I have to doing my work? These questions are designed to ensure that all team members know what everyone else is doing regardless of if one or another team member thinks something is “important” to know. This transparency gives the team a regular rhythm of “Inspect and Adapt”. Since the Daily Scrum is meant to be short, any discussion of the work should be held until after the Daily Scrum is complete. To be clear: the Daily Scrum is not meant to be a problem solving meeting and treating it so can lead to people failing to be as transparent as needed (or to breaking the timebox for the Daily Scrum which leads to other problems).
The Daily Scrum is most effective when it is held at a regular time of day so that all team members can easily remember it, schedule for it, and it becomes a habit for the team. Although technically this is simply a guideline rather than an “official” rule, it nevertheless has a positive impact when done, and a negative impact when not done. If the team fails to have the Daily Scrum at a regular time, Team Members will need constant reminding of when it is going to occur, and there is a greater risk that it will be missed by some Team Members. Missing the Daily Scrum reduces transparency between Team Members. Another minor negative consequence is that if the Daily Scrum is not held at a regular time, then the Sprint Burndown Chart will have an uneven horizontal scale (if measurement is made at the end of the Daily Scrums) or it will be more difficult for the ScrumMaster to measure the state of the Sprint for tracking on the burndown (if measurement is made at a regular time of day independent of the Daily Scrum).
The Daily Scrum is designed to dramatically improve transparency among Scrum Team Members and out to any stakeholders who are interested in observing the meeting. The timebox is a fixed limit on the duration of the meeting. The 15 minute limit on the Daily Scrum is sufficient for each Team Member to take a turn and briefly answer each of the three questions required in the meeting. The timebox forces the Team Members to be brief, to be focused, to be on-topic and to be respectful of other Team Members’ time. If the Daily Scrum meeting takes longer than 15 minutes, some Team Members and stakeholders will stop feeling like the meeting is worth the time investment, particularly since it is daily. Even five additional minutes for a 12 person team adds up to a person-hour of time lost every day! Losing people’s interest or respect for the meeting will decrease transparency and can hamper the team in numerous ways, including the ScrumMaster’s ability to see and deal with obstacles in a timely manner.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the combined length of the Sprint Review and Retrospective Meetings is determined by the length of the Sprint. For example, a one week long Sprint has Sprint Review and Retrospective Meetings that are timeboxed to two hours in total. It is acceptable for the meetings to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Review and Retrospective Meetings timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective inspect and adapt in a very short period of time. If the meetings are not timeboxed, then typically the team will keep going until they are “done”… and break the timebox of the overall Sprint.
The last part of the Sprint is the Sprint Retrospective. This meeting is a private meeting for the members of the Scrum Team (including the ScrumMaster and Product Owner). In this meeting, the Team Members discuss how they did their work during the past Sprint and come up with ways to improve their work in the next Sprint. Scrum does not define any particular techniques to use during the Retrospective meeting. The Retrospective is complementary to the Sprint Review. The Review inspects “what” was done and the Retrospective inspects “how” it was done. The Sprint Retrospective is critical for the team to apply the principle of “inspect and adapt” that is core to Scrum. Missing the Sprint Retrospective is a critical failure of the ScrumMaster’s job to ensure that the principles of Scrum are being used. If a Retrospective is missed once, what may happen is that some Team Members might feel that missing it was not so bad. There will not likely be any immediate consequences to missing the Retrospective. However, the attitude that the Retrospective is not important will be implanted in the team. This then quickly leads to further compromises and eventually, the continuous improvement parts of Scrum are abandoned and the team focuses purely on the execution parts of Scrum. The team will then fail to become a high-performance team since that high-performance state is predicated on systematic, conscious self-improvement of how the team does its work.
Scrum is a tool for product development that uses transparency and fast feedback. The Sprint Review is an open meeting during which the Scrum Team works with all interested stakeholders to look at the results of the Sprint. This meeting is usually dominated by a demonstration of the working increment of software. The stakeholders in attendance at this meeting freely provide feedback about the product which is then used by the Product Owner to update the Product Backlog. This feedback is critical to ensure that the team is staying on-track, that it is building the most valuable possible product features, and that the stakeholders are satisfied with the results. Missing this aspect of feedback makes Scrum only modestly better than non-agile approaches to doing work and should be considered a critical problem to fix as it undermines the whole point of doing Scrum.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the length of the Sprint Planning Meeting is determined by the length of the Sprint. For example, a one week long Sprint has a Sprint Planning Meeting that is timeboxed to two hours. It is acceptable for the meeting to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Planning Meeting timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective planning in a very short period of time. If the meeting is not timeboxed, then typically the team will keep planning until the plan is “done” which usually substantially eats into work time.