This is a full transcript of the House of Scrum – The Framework Overview video I recorded last year.
The House of Scrum is a metaphor for the Scrum Framework I came up with sometime last year. And it turned out to be a helpful way to explain the framework to people who would like to learn more about Scrum. So let’s get started.
Scrum is a framework that people use to address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is lightweight simple to understand and difficult to master. As Ken Schwaber, the co-creator of Scrum said the framework takes two days to learn in the lifetime to master.
It’s very important to understand that Scrum is not a method, process, or technique. It’s a framework. The framework can use various processes and practices within itself. The House of Scrum is built on a solid foundation of empirical process control or empiricism. Empiricism says that knowledge comes from experience and experimentation and the best decisions are made around what known. So what it means it basically says, try new things, validate your hypothesis, learn new stuff, and then go and make better decisions.
The empiricism has three pillars. These are transparency, inspection, and adaptation. And as we’ll see later, these three pillars lend themselves really well to the Scrum Framework.
Transparency requires that the process is visible to its participants. Two examples of transparency in Scrum Framework are a common language that should be shared by everyone, and the Definition of Done to ensure everyone is on the same page in the understanding of the state of work.
In Scrum, we frequently inspect its artifacts and progress towards a Sprint Goal. How often do we before the inspection? Well frequent enough as not to let the problems fester and accumulate, but not as frequent as for the process to get in the way of work. Inspection is best done at the point of work by those who are most qualified to inspect Scrum artifacts. If the inspection uncovers some variances from the desired outcome they should be fixed, and that’s where adaptation’s coming in. Just in time adaptation is best as it prevents further deviations.
Scrum adds another layer to the foundation. Think about it as a level that raises your house above the floodwater quite a useful concept here in Houston. This level consists of Scrum values and those values are courage, commitment, focus, openness, and respect. If you want an easier way to remember these I use the acronym CCFOR or double-C4
Scrum Team members are courageous to do the right thing to achieve the goal and the work on tough and complex adaptive problems. They are committed to achieving the goals of the Scrum Team. Scrum Team focuses on both the work done in the Sprint and the goal of the team. Stakeholders and Scrum Team, Scrum Team members, agree to be open about the work, open about the process and challenges with those. And last but not least, we expect people to be capable and independent individuals.
I want to dwell a little bit more on this last one. Explaining the value of respect I always like to expand on the Scrum Guide definition. For me respect goes in all directions it goes laterally. We respect our customers; we focus on delivering the right thing with the highest quality. We respect our suppliers, for example, not asking for what we don’t need. Respect goes down to the subordinates, and it goes up to the managers. Respect goes in all directions and it’s absolutely crucial for the smooth functioning of a great Scrum Team.
Now let’s move on to exploring the rest of the Scrum Framework which is also known as a 3-5-3 framework. Scrum Framework has three artifacts, five events, and three roles. Hence 3-5-3 framework. The rules of Scrum, bind artifacts, events, and roles altogether. Artifacts are transparent, events are formal opportunities to inspect and adapt, and roles come with a set of their own accountabilities.
So let’s start with artifacts and there are three of them. These are Product Backlog, Sprint Backlog, and a Done Increment.
Product Backlog is an ordered list of everything that can potentially make its way into the product. Product Backlog items comprise Product Backlog and can be expressed as user stories, defects, features, technical work, learning hypothesis, or everything. Everyone can contribute to the Product Backlog, but the Product Owner is responsible for its ordering. Order is not a priority. The order includes dependencies, cost, risk, value. It is quite more than just priorities.
Product Backlog is never complete as long as the product exists. It is dynamic and emergent. As new information becomes available Product Backlog might be adjusted to reflect it. Product Backlog is detailed through a continuous process of refinement, not an event. And that process takes no more than 10% of the Development Team’s capacity. Product Backlog is transparent to everyone through its ordering and inherent value.
Sprint Backlog, though a backlog as well, is quite different from the Product Backlog. Sprint Backlog contains Scrum Team’s forecast of work they will do in the Sprint and a plan on how they will convert chosen PBI items into the Done Increment. Development Team owns Sprint Backlog and only the Development Team can change that.
Sprint Backlog can, and probably will change. And that goes against the grain of some people’s saying, “Oh, Sprint Backlog never changes after Sprint Planning is done.” It will change. And as the work is being performed, new things are learned and uncovered, and they will be required to achieve the Sprint Goal. Some items might become obsolete and will be removed from the Sprint Backlog. So Sprint Backlog can and will change.
Sprint Backlog is emergent as is Product Backlog. The what might change as the new learnings are obtained, and how might, and probably will change, as the Development Team inspections its progress towards the Sprint Goal at least daily.
Last but not least, Increment or Done Increment, which is the sum of all work done in the current Sprint, and the value of all increments from previous Sprints. Scrum requires Done Increment to be available at least at the end of each Sprint. Done means usable in accordance with a Definition of Done. It doesn’t mean it has to be released but it should be potentially releasable.
This also doesn’t mean that Scrum prevents you from having a Done Increment at any point in time within a Sprint. The Increment emerges as well. You see all the artifacts are emergent artifacts by nature. And it is been added to every time a Product Backlog item is getting done. The Done Increment is transparent and it’s done in accordance with the Definition of Done and inspected by the Scrum Team and stakeholders to determine further development directions.
Now, let’s move on to the right or your left; to the roles was their accountabilities, And there are three of them, Product Owner, the Development Team, and the Scrum Master. Let’s start with the Product Owner.
The role of the Product Owner is hard. She is the chief value maximizer responsible for getting the most valuable pieces in customers’ hands. She is solely responsible for managing and ordering the Product Backlog. The concept is widely misunderstood. The Product Owner can, and probably should delegate the writing of Product Backlog Items and refinement process to others, but she cannot delegate the responsibility of ordering of those Product Backlog Items.
I recently got a question about whether stakeholders can write Product Backlog items and contribute to the Product Backlog and the answer is, “they absolutely can as long as the Product Owner role and its accountabilities remain intact.” So, another important thing to remember that the Product Owner is a single person and not a committee. Hence a single suite, single occupancy suite here, in the House of Scrum. He is the only person who is responsible for ordering the Product Backlog. The entire organization must respect the Product Owner’s decision for this role to be successful.
The Development Team is accountable for delivering potentially releasable Done Increment at least at the end of every Sprint. Development Teams are self-organizing, and it behooves organizations to empower the teams to be self-organizing entities from their formation to getting work done.
Development Teams are cross-functional. And I hear a lot that cross-functionality means that everybody on the team should be able to do everything. That will make the team cross-functional for sure. But that’s not the point. The point of cross-functionality is that the Development Team has to have all skills necessary to get work done with little or no external dependencies.
There are no titles on the Development Team. Every team member is a team member. There are no sub-teams, there are no frontend team, backend team, or any other subteam. Everyone is guided by a single Sprint Goal and doing everything necessary to get the work done.
The size of the Development Team is three to nine team members. If there are less than three members on the Development Team, the team will likely just struggle to get meaningful work done by the end of the Sprint, and they will probably not have all the skills necessary to get the work done. If there are more than nine team members on the Development Team, then the communication will get cumbersome and the complexity will rise which is not desirable.
And last but not least the Scrum Master role. Scrum Master is accountable for promoting and supporting the Scrum Framework. Scrum Master is a servant leader whose success is realized through the success of those she serves. Scrum Master teachers organizations which interactions with Scrum Teams are useful and which are not. Experienced Scrum Master serves the Product Owner, the Development Team, and the organization as a whole.
Now let’s move on to the events which as you remember our form of opportunities to inspect and adapt, and there are five of them: the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
The events are designed to provide cadence and regularity. This ensures that the benefits of these events will happen rain or shine at preset time intervals. The events are time-boxed, meaning they have the maximum duration set. An event usually ends when the time box expires or the goal of the event is achieved. With the exception of Sprint, all it means is that if you got what you need out of your event, get out, end the event.
Sprint is a container for all other events and its time box is one month or less. Some prefer to mention four weeks as it’s more aligned with the way they work. Sprint may be considered a project of one month or less duration. No changes made within a Spring that would endanger Sprint Goal. Quality and quality expectations do not decrease during the Sprint. Therefore it’s a bad idea to change the Definition of Done outside of Sprint Retrospective during a Sprint.
The scope of work within the Sprint can be changed and will be clarified between the Development Team and Product Owner as the new things are learned and as the work is being done.
A couple more things about Sprint. There is no Sprint zero. All work is done within a Sprint and leads to a Done Increment. There are no hardening Sprints, there are no testing Sprints, there are no UX Sprints. Each and every Sprint leads to the achievement of a Sprint Goal and creation of a done, potentially releasable valuable increment.
Sprint can be canceled by the Product Owner, if and only if, the Sprint Goal becomes obsolete. Sprint cancellation is quite a traumatic event for the Scrum Team because the work was done, efforts were wasted, time was wasted, and with Sprint’s being so short, the four weeks or less, there’s rarely a reason to cancel a Sprint.
Let’s move on to Sprint Planning. The goal of Sprint Planning is to plan the work to be executed during the Sprint. It’s timeboxed to eight hours for a one-month long Sprint. For shorter Sprint’s the amount is usually shorter. Just notice that we do not say that is proportionally shorter. It is shorter.
Sprint Planning usually consists of two parts. In the first part the Scrum Team decides what it will be working on and as a result crafts the spring goal. In the second part the Development Team decides how to convert selected PBIs – Product Backlog items into the down increment.
Daily Scrum is the Development Team event. It’s an inspect and adapt event for the Development Team. And this event is time-boxed to 15 minutes or less.
In this event Development Team inspects its progress towards the Sprint Goal and adapts its plan to ensure the goal is still achievable. Remember the Sprint Backlog, the what part and the how part? That’s what’s been inspected here and adapted here in the Daily Scrum.
Daily Scrum is not a status report meeting. And while the Scrum Guide suggests the content for the Daily Scrum, the Development Team should and probably need to figure out the best way to conduct its inspect and adapt event.
What’s the role of Scrum Master there? He or she will ensure that the Development Team has the meeting, the meeting occurs, and preferably at the same time in the same place. Scrum Master teaches the team to keep the event under 15 minutes. And if others are present in the meeting, Scrum Master ensures that they know and respect the fact that Daily Scrum is an internal Development Team event.
Let’s talk about the Sprint review. Sprint review occurs at the end of the Sprint and is an opportunity to inspect the Done Increment and collaborate with the stakeholders on what’s next. While demoing the increment could be a part of the review, it’s not the main point of that event. And the Sprint review is timeboxed to four hours or less for a one-month long Sprint.
All Scrum Team members are present in the event to ensure that sharing of learnings, ideas, and future directions are maximized. This is a great event to bring up budgets, to talk about market directions, to discuss future plans, release plans, to share impediments and problems with work and product.
As a result of the Sprint Review, we will adjust the Product Backlog. The Product Backlog is adapted to reflect possible PBIs – Product Backlog items for the next Sprint.
And the last but not least Sprint Retrospective. You probably remember that at regular intervals the team reflects on how to become more effective, and then tunes and adjusts his behavior accordingly. This is the 12th principle behind the manifesto for Agile software development, and it’s the heart and soul for Sprint Retrospective. The whole Scrum Team participates in the event and the event is timeboxed to three hours or less for a month-long Sprint.
The outcome of the Sprint Retrospective is at least one improvement item that the Development Team agrees to work on in the next Sprint. And in order to be held accountable and in order to make it transparent, it’s put on the Sprint Backlog. Can improvements be identified outside of the retrospective? They absolutely can; remember that all these events, they are formal opportunities to inspect and adapt. You can inspect and adapt much more often than that.
So, you will ask, “what about these concepts of Definition of Done, Sprint Goal, and Product Backlog refinement?” Well, Definition of Done is not an official artifact and neither is Sprint Goal, and Product Backlog refinement is not an event. And I think this one is probably the simplest to explain. Product Backlog refinement is a continuous process and, apparently, Scrum Guide authors didn’t feel the need to introduce a cadence for that process. All they say is that Product Backlog refinement is beneficial, it’s a good process, and should take no more than 10% of Development Teams capacity.
Sprint Goal is mentioned 27 times in the latest iteration of the Scrum Guide, and it’s not an artifact. I personally prefer to think about a Sprint Goal as the third overarching part of the Sprint Backlog. Sprint Goal is crafted in the Sprint Planning. Sprint Backlog most likely is full of activities that support the achievement of Sprint Goal, and Sprint Goals lifespan coincides with that of the Sprint duration and the lifespan of the Sprint Backlog.
Definition of Done is a completely another topic and deserves absolutely separate conversation. All I will say here is that while other artifacts are transparent, the Definition of Done in my mind is what provides that transparency, embodies that transparency as it provides a common understanding of the qualities of the Done Increment, for example.
