At its core, the Scrum framework is simple, and held up by the 3-5-3 structure: 3 Roles, 5 Events, 3 Artifacts.  You need all of these elements to be doing Scrum, nothing in there is optional. Leaving out any of the parts means you are not doing Scrum. Ken Schwaber once likened Scrum to chess, and it’s an excellent analogy.  You can’t just change the rules of chess and still claim to be playing chess; there are no house rules.  If I decide that the queen can jump pieces in her way to get to another piece, I have an entirely new game (and a bad one).  Scrum gives you a lot of freedom in how to make it work within your organization, but you have to still follow the basic rules.

3 Roles

Product Owner – WHAT

The Product Owner owns the Product Backlog.  She is solely responsible for its upkeep, and how Product Backlog Items are prioritized according to their value.  Only the Product Owner can make decisions on value, and her word is final. A good PO will have a vision for the product that can be executed by the Development Team.  She is responsible for aligning with both the Development Team and other teams to make sure the vision is attainable. The Product Owner should be always available to the team to answer questions and provide guidance into work, to look at work in progress and make sure it aligns with her vision, and to ensure that the correct value is being delivered by the team.  She is also responsible for communicating with customers and stakeholders, gathering information and requirements that can be turned into future PBIs, as well as showcasing DONE work for everyone to see early and often. The PO doesn’t tell the Development Team HOW to do the work, but trusts that they have the knowledge and expertise to make her vision a reality. Without a strong Product Owner, it becomes impossible to order the Product Backlog meaningfully, to determine what will add the most value, and to engage stakeholders to get them behind the product we are building.

Development Team – HOW

The Development Team is responsible for getting the work selected in their Sprint Backlog to Done.  They solely own the Sprint Backlog, and nobody can make changes to it without the team’s acceptance.  A great team is both self-organizing and self-managing; they decide both how they are going to work, and what work they are going to do within a Sprint to maximize the value they are creating.  They are able to negotiate with the PO to get the right work into a Sprint, and to create a Sprint Goal. They are cross-functional – no internal team silos – and collaborative. They know best how to work together to be great.  Without a great Development Team, the Product Owner has no way of creating a high-quality, high-value product.

Scrum Master – PROCESS

The Scrum Master is responsible for making sure that Scrum is being followed. He is a coach, a mentor, a facilitator, and an ardent defender of the Development Team.  He is willing and able to aggressively remove impediments quickly. A good SM is focused on how to make his Scrum Teams the best they can possibly be, to drive them toward making improvements and delivering the value they have forecast.  He makes work visible using information radiators of all kinds. He is creative with his approach on how to work with the team and is willing to try anything if it might work, while adhering to the Scrum framework. He knows that the team’s success is his success, and is largely external to the process of how the team functions. Without a great Scrum Master, the team has no way of knowing they are succeeding with Scrum, that impediments are being removed, and that they are finding ways to continuously improve over time.

5 Events

The Sprint

The Sprint itself is the beating heart of Scrum.  This is the steady rhythm at which the Scrum Team works, and in which value is created.  Whether the length of the Sprint is one week or four weeks, it provides clear boundaries for the team, and enables a frequent feedback loop to make sure we are delivering value to our customers on a regular basis.  Every other event in Scrum depends on the Sprint itself. Without the Sprint, there is no cadence to work being delivered, there is no feedback loop allowing the team to make changes, and there is no rapid release of high-quality product.

Sprint Planning

Sprint Planning is where the Development Team works with the Product Owner to take on high-value work to create a new Increment.  This is the chance to not only decide what to work on, but to come up with a plan on how to get that work done. Without Sprint Planning, there is no good way to formally agree on what work will be done and how to do it.  

Daily Scrum

The Daily Scrum is how the team gets together once per day for no more than 15 minutes to talk about what work has been done and to plan the next 24 hours.  The Daily Scrum meeting – though often called a Daily Standup – does not require the team to be standing (though it is considered a best practice for co-located teams).  It’s also not a status report from everyone on the Development Team. Team members should be talking to each other and planning their work, not reporting to the Scrum Master and/or Product Owner to show progress toward a goal.  In fact, it is not even necessary for the SM or PO to attend the Daily Scrum (though I do encourage it, in case questions arise). Just as the Sprint itself provides a rapid feedback loop, so does the Daily Scrum. This is a daily Inspect and Adapt event that allows the team to quickly change course if something needs to be corrected, and to make sure that they are on target to meet the Sprint Goal.

Sprint Review

The Sprint Review allows us to show work that was Done within a Sprint to our stakeholders, to get their insight on where we might be able to make our product better, and to get them excited about what has been done and eager to put our product to use.  Much of what we intend to do next in a Sprint comes from the Sprint Review! Without this, we are working blindly and hoping that we are truly adding the value our stakeholders desire.

Sprint Retrospective

The Sprint Retrospective is where the Scrum Team gets to talk about how the Sprint went, and discuss how to make the next Sprint even better.  This is the most important Inspect and Adapt event we have in our toolbox. The Sprint Retrospective can take many forms, but it should ultimately yield one or more action items that the team wants to take on during the next Sprint to improve how we work together.  

3 Artifacts

Product Backlog

The Product Backlog is the Product Owner’s vision for the Product.  It is maintained in real-time, and just-in-time to keep just enough work for the next several Sprints in scope.  There should not be work on the backlog that the Product Owner doesn’t feel will be touched for months. While it’s important to keep track of that work for the future, it should be kept apart from the Product Backlog and only brought in as it gets close to a point where that work is valuable.  The Product Backlog is a living artifact that is continually updated, ordered by the PO to make sure that the highest value items are always at the top. The Product Backlog acts as a medium-range view of the Product Roadmap, providing clarity into what is coming in the near future.

Sprint Backlog

The Sprint Backlog is a child of the Product Backlog, consisting solely of PBIs that the Development Team is forecasting to be done in the current Sprint.  The Development Team can, and should, negotiate this with the Product Owner to make sure that the highest value items are getting worked on, while the Scrum Master serves as a check to ensure that the Development Team doesn’t commit to more work than they can fully accomplish.  This is immediate term planning that will result in an updated Product Increment.

Product Increment

The ultimate output of a Sprint is a Product Increment.  This is a finite piece of DONE work that has been fully reviewed by the Product Owner and stakeholders and *may* be ready to be released into Production.  Not every Product Increment is a Production Increment. The Product Increment delivers on the value promised by the Development Team in accordance with the Sprint Goal and their Definition of Done.

What Isn’t There?

There are some things that are extremely important that are explicitly NOT in the Scrum Guide as one of the Roles, Events, and Artifacts defined.  That doesn’t mean that these things are suddenly unimportant or useless to the organization, just they are not inherently a part of Scrum.