According to the Scrum Guide, “Scrum is a framework for developing, delivering, and sustaining complex products.” Scrum is a collection of roles, events, artifacts, and rules that help teams work together more effectively and harmoniously. It’s been in wide use for over twenty years in a variety of industries, ranging from software development where it is best known to hardware development, marketing, and even nonprofits.

Because Scrum is highly compatible with the Agile Values and Principles, practitioners consider it to be an Agile framework, along with Lean, Kanban, XP, and many others.

Let’s start with our company’s vision: our mission. This is why we show up to work every day, right? If you’re in a bigger company, you might have multiple products, each with their own vision. Either way, you’ve got a sense of where you want your company or product to be over the course of the next one to three years or so.

Personally, I think it’s useful to write visions from your customer’s perspective. One company vision statement that I really like is Amazon’s: “Our vision is to be earth’s most customer-centric company; to build a place where people can come to find and discover anything they might want to buy online.” Compare this to a vision statement like “We’re the biggest online retailer in the world.” Another way of thinking of this is: your vision statement reflects your big impact on the world, the value that we wouldn’t have if your company didn’t exist, or to use Steve Job’s terminology: “Your dent in the universe.”

Your vision should be succinctly stated, right-sized in scope, and realistic enough given your current and likely future capabilities. Visions help us understand the strategy, while having a roadmap helps us understand our tactics and desired timing. While a vision helps us understand where we want to be in a few years,   Either way, your roadmap is still just a wish list based on the information that you have available to you now; it will almost certainly change over the course of the next few quarters. If it doesn’t, this should be a huge red flag that you’re not incorporating enough feedback from your users quickly enough.

One of the biggest ways a technology company creates positive user outcomes is to output reliable working software. Notice that there’s a difference between output and outcomes: you probably need some working software to get positive outcomes for your users, but there’s no guarantee that your particular set of outputs will produce the desired outcomes.

Working software is just half the battle. If you want to keep building working software quickly in the future and keep your customers happy, you’re going to need to make sure that you’ve built the software well.

Agile teams use a Definition of Done to help them determine whether or not their software meets their quality bar. It’s a documented team agreement that specifies the conditions that must be met—such as automated testing and scalability—before the team calls it “done as in done.” This helps protect the team from building up costly technical debt.

Ok, so over what time horizon are we talking about? Scrum teams complete work in 1-4 week cycles known as iterations or sprints. The team expects to create a “done,” demonstrable, and potentially shippable product increment. Based on my experience coaching dozens of teams, I now suggest 1-2 week sprints. 3-4 week sprints don’t allow teams to iterate quickly enough, and allow for nasty anti-patterns to creep in.

What work will they complete in that sprint? The team will refer to a Sprint Backlog, a prioritized list of the most valuable work that is ready for the team to work on now. The team doesn’t strictly guarantee that they’ll get all of this work done—it’s just a forecast—healthy teams should be able to fully complete somewhere between 85% and 115% of what they planned on. Let’s take moment for an important discussion: Why do we say this is a forecast instead of a commitment? It turns out that the official Scrum Guide used to say commitment, but they changed it in 2011 because, quote, ”reality keeps on showing us that it is difficult, if not impossible, to always fulfill this self-imposed commitment without making compromises to quality… On the other hand, the chosen alternative “forecast” has to do with making assumptions based on reliable information and evidence. This is much closer to how an experienced Scrum Team works.” That said, the team should feel comfortable committing to the Sprint Goal, which should be written in such a way that it can be accomplished even if not all of the items in the sprint backlog are completed.

Where do they get the work for the sprint backlog? They get it from the Product Backlog, a prioritized list of work that the team intends to work from now to the medium-term future. Product backlogs contain every piece of work your team plans to work on. Work that you plan to do in the next sprint or two will be granular and captured with detailed acceptance criteria, while work that you don’t plan on doing for another several months will be less granular and should have just highlights of what you hope to accomplish.

By the way, the official Scrum Guide calls this a Product Backlog, but I think Team Backlog is more accurate. This is because a single team may be working on multiple products, but should only work from one backlog.

Notice how some of the work on your product backlog will be ready to work on, while some isn’t. How do we prevent items from making it onto the Sprint Backlog before it’s ready? We use a Definition of Ready: a documented team agreement that specifies the conditions that must be met—such as being the right size and having clearly-articulated acceptance criteria that the team understands—before the team pulls the item into the sprint backlog.

So who are the people doing all of this work? First, we have the Product Owner. They are responsible for maximizing the outcomes and impact from any given set of output that a team might produce. What this means is that two development teams may write the same amount of software, but the software that one team produces could be far more valuable to users. That team probably had a more experienced and empowered product owner. This individual has an incredibly important role, and they need to be fully enabled by their organization to set the product direction.  In a nutshell, the product owner is responsible for “what” and “why” – what we’re building, and why we’re building it.

Next, we have the entire cross-functional development team. Some companies think that just software developers belong on the development team. I think that’s short sighted: I’ve found that teams are far more functional when a wider breadth of skill sets, such as user experience, quality assurance, and operations. Just as product owners must be empowered to decide what to work on, the development team must be empowered to determine how and when: how we will meet the desired user outcomes, and when it will be potentially releasable.

You’ve probably figured out that the product has a need for speed, while the development team has a real need for quality. They’re both right.  Who keeps this all in balance? That’s right: the Scrum Master.

The Scrum Master is responsible for coaching both the PO and delivery team on effective Scrum. They teach and reinforce Scrum values, principles, and practices. They are a servant-leader for the product owner, development team, and broader organization.

So how do we make work ready? Once or twice a week, the whole team gets together — Product Owner, Scrum Master, and Development team — and reviews and refines the product backlog together. We call this event Backlog Refinement, though some people may refer to it as backlog grooming. The product owner brings up user stories and begins a clarifying conversation with the team to improve the quality of each user story. For instance, suppose the product owner says they would like a cup of “hot” coffee. A member of the development team might ask: how hot is hot? After a brief conversation, they’ll decide on a more objective measurement of temperature and update the user story. Our goal will be to have 1-½ to 2 sprints worth of “ready” stories by the time we start our next sprint.

The sprint itself begins with Sprint Planning. The purpose of sprint planning is to a) determine what can be most likely be delivered in the next sprint and b) come up with a high level plan for how that work will be accomplished.

Only the development team can decide what it can accomplish over the upcoming sprint. They will do this by considering the work completed and left incomplete from the prior sprint, the team’s capacity this sprint, and the team’s historical performance. Teams often over-commit, either due to pressure from the Product Owner or a naïve optimism. The Scrum Master discourage this with effective coaching.

Having determined a reasonable Sprint Backlog, the development team decides together how it will complete the work this sprint. Most teams decompose user stories, bugs, and other product backlog items into more granular tasks, generally a day or less in duration. This is effective because the high-level design of the software occurs in a high-bandwidth, facilitated event, with all subject matter experts present.

Now that the team has kicked off their sprint, they’ll check in with each other every day in a event called the “Daily Scrum” or “Daily Standup.” This is a 15-minute time-boxed event that allows the Development Team to synchronize their work and plan for the next 24 hours. It is held at the same time and place every day.

During the Daily Standup, development team members frequently answer:

• What did I do yesterday that will help our team meet our sprint goal?
• What will I do today that will help our team meet our sprint goal?
• Do I see any impediments or blockers that will prevent me or the team from meeting our sprint goal?

Many teams will also use this opportunity to review the quantity of remaining work and come up with a mitigation strategy if the team isn’t on track to meet their sprint goals.

At the end of the sprint, the team will demonstrate their work to customers and other stakeholders at an event called “Sprint Review” or the “Demo.” At a minimum, the team will demonstrate completed work, solicit feedback, and answer questions. Teams will also often discuss the current product backlog, recent developments that may justify a plan change, and any notable metrics.

Finally, the sprint concludes with a retrospective. This is when the whole team inspects its own performance and creates a improvement plan for the next sprint. It occurs after the review and before the next planning. Together, the team will inspect how the sprint went in terms of team culture, structure, processes, and tools. From there, it can identify major opportunities to persist what went well and change what didn’t. Lastly, the team will come up with plan for continued self improvement, usually through actions, experiments, or changes in team behavior in the next sprint.

There’s a few roles that aren’t part of official Scrum, but can be found in nearly every organization.

First, we have our stakeholders. They are—in theory—our best proxy for our end customer or user. It’s tempting for a stakeholder to attempt to exert undue influence over the team to prioritize the stakeholder’s requests. Some companies may create incentive structures that don’t reflect reality, such as several stakeholders whose bonuses all depend on getting a feature shipped this quarter, even if the team can deliver only one. A good product owner can effectively work with disparate stakeholders and create a roadmap and team backlog that maximizes value for the whole company.

Next, we have our managers, everyone from engineering managers to product directors. As teams move to becoming highly autonomous and self-organizing under Scrum, the traditional command-and-control role of managers must be abandoned in favor of servant leadership. This change can be extremely difficult for many managers: in fact, it requires a much greater degree of psychosocial development and emotional intelligence. A skillful Agile Coach or Scrum Master, if empowered, can help managers make this transition.

Which leaves us last with our executives, which covers almost everyone with a “Chief” role as well as everyone on the board. These individuals are far and away the single greatest factor in whether or not any Agile Transformation will be successful. They define the company’s culture through the behavior that they exhibit and promote… literally! A leader, such as an engineering manager, cannot create safety and autonomy for their teams if they do not feel safe under their leaders as well. If we promote a manager with a habit of barking command-and-control orders, all of the feel-good “culture events” and posters won’t foster the development of true servant leadership in the organization.

So, we talked about the fundamental roles, artifacts, and events that you’ll find in an organization that is practicing Scrum well. What’s the end result? Let’s suppose we create the right culture, build an effective organizational structure, and let team’s define the processes and tools that work best for them (after practicing textbook Scrum long enough to fully internalize it. What do we get?

We create an environment where EVERYONE feels empowered to CREATIVELY solve the problems.