By Dan Rawsthorne and Douglas E. Shimp
Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe Scrum as a simple applied model so that a central understanding of Scrum can be built. Other complexities of applied Scrum such as scaling, distribution, etc. will be explored elsewhere.
The Team
The fundamental element of Scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of people that provides useful Results/Products for Stakeholders.
Arguably, the most important role involved in Scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special Stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the Team to form.
While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the first person held accountable for the Team’s success. The Product Owner must find a result that will satisfy the Stakeholders’ needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.
The Scrum Team Members, including the Product Owner, are the people who actually do the work that satisfies the goals and priorities the Product Owner has set for them. The Product Owner must work with the Team to find a rate and direction that the Team can go, to achieve a desirable result. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings; whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve; they work on the priorities the Product Owner has set. The Team Members commit to the amount of work they can do without undue influence from the Product Owner.
In order to aid the Team (Product Owner included) in doing its work, there is a role on the Team called the ScrumMaster (SM). The SM's responsibilities are to be a facilitator, moderator, and coach, with particular emphasis on helping the Team mature its self-organization and management. The ScrumMaster manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team, often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the Team and outside the Team. The ScrumMaster understands the Scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to. If the Team does not follow its process this becomes an impediment. Most impediments can be addressed by simply causing them to become a center of focus. The SM stimulates that center focus by calling attention to the impediment. Creating a smart center of focus is the art of being a SM.
The Backlog
A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs," "Backlog Items,” or simply "Items"). When the list is small it is just a straight list of things, but as it grows we add grouping mechanisms to organize many little things and help us keep track.
These Items represent the Stakeholder's needs and wants – each of them is a request for something of value from the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of Scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few Items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that Backlog and thus, creating a distinction between the Sprint Backlog and Product Backlog. From the Team’s perspective, the Product Backlog is work that we might do some day, and the Sprint Backlog is work we are committed to doing.
The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: “ready” does not imply excessive detail but, instead refers to enough detail. The Team working with the PO will determine what “enough detail” is.
When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, and refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify Backlog Items. This process is called Backlog Grooming, and is a continuous process throughout the Project.
Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.
The Release
The goal of a Scrum Team is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).
Typically, before a project formally begins, there is a Visioning phase (this could also be the first phase in a project), when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.
The Scrum Team’s purpose is to create a result that satisfies the Stakeholders’ needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on Items. The Sprint length can vary, but this requires more discipline on the part of the Team and is not advisable for new, less mature teams. The steps of a Release are relatively simple, and I'll describe them here.
Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation considers the Product Vision and Roadmap, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and results in a set of Release Goals and a Release
Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.
Once we have a Backlog that supports the Release Goals and Strategy, the Team starts sprinting. The idea is for the Team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.
The Sprint
The fundamental process flow of Scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results.
The first thing to do in a Sprint is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of "Done," and collectively these Items are called the Team's Sprint Backlog. It is the ScrumMaster’s responsibility to ensure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the Team confidence that it can complete the Item, and thus commit to it. The tasking of Items can help the Team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the Team is working well.
Once Sprint Planning is over, the Team begins work in the Sprint. The Team self-organizes to do the work and self-manages as it does the work. The Team’s work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing Teams that looks like a swarm to an observer. While the Sprint is in progress, the Team will have Daily Scrums in order that each Team Member understands what the Team's status is. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the Daily Scrum.
During the Daily Scrum, and continuously throughout the day, the Team Members notify the ScrumMaster of any impediments they encounter. It is the ScrumMaster’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.
The ScrumMaster must also ensure that the Team does enough Backlog Grooming in order to be prepared for the next Sprint's planning meeting. The Backlog Grooming is a strategy to prepare enough work to begin next so that a rhythmic flow of work can happen.
When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the Team's Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so the Team can get feedback on what they've done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), considering the Review and any "business reality" changes the Stakeholders may have. When Teams are small they can rely on more intuitive reasoning to determine what the "right direction" is. As a Team grows they will see a need for more sophisticated techniques that use metrics to help them answer what the "right direction" is.
After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The Team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be "enforced" by the ScrumMaster in future Sprints. To enforce something the SM will need to shift the focus to the issue at hand and then let the Team react. Telling the Team what to do is not desirable. Shifting the Team focus and thereby enforcing change is an art of the SM.
At this point the Sprint is complete, and the Team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.
Quick Summary
Team of 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross-functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily Scrum detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance
