Learn Scrum the right way! This is a one hour fifty minute condensed version of my otherwise one day Scrum Crash Course that I give to leaders and teams that are about to embark on a Scrum product development journey. Although it is hyper condensed, no corners are cut short as I insist: when we do Scrum, we do proper Scrum.
Welcome to my Scrum Crash Course. Hi, I’m Coach Takeshi. If we’re going to do Scrum, let’s do Scrum properly. No “scrummy”, or “pick and chose” scrum, ok? So we’ll learn Scrum in its entirety, and this crash course will cover what we need to know about Scrum from beginning to end, with no corners cut short.
Ok, so before you start. You’ve been already given prep instructions separately, so just a quick recap.
First, if you haven’t watched the Agile 101 video yet, please do so. Please do not proceed to learn Scrum before first learning and thinking WHY we do agile. A meta thinking process of, for example, why we do things in iterations in agile, and in agile why we no longer seek instructions from bosses and managers but decide on our own what to do and how to do things; without these thinkings, we might end up just learning Scrum as going through the motions, mechanistically. The worst type of Scrum is project “managed” Scrum – Scrum is for product “development”, let’s make sure we understand the difference before we start.
And have you already read the Scrum Guide? Although we will cover the Scrum Guide thoroughly in this crash course, this course is not a substitute of the Guide, so please read. It’s only 14 pages. Also, Gunther Verheyen’s Scrum Pocket Guide is very useful in getting a grasp of the whole flow of Scrum, so at least please read chapter 2 of that book.
And finally, after today’s crash course, the real learning of Scrum happens at the “Gemba”, which is a lean term that means “the place of action”, so do practice Scrum. If you are an aspiring agile coach, please do not coach Scrum without first immersing yourself in the practice. Opportunities abound. Perhaps just call up a VC friend and ask to be introduced to a startup company in their portfolio, and offer yourself as a free or cheap Scrum Master.
The 2020 Scrum Guide defines Scrum as the following. Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. There are a few highlights here. The first one is Scrum is a lightweight framework. The second part is about value generation and the third part is that Scrum is a solution development framework for complex adaptive problems. Scrum is simple. The Scrum framework is purposely incomplete. Various processes, techniques and methods can be employed with the framework. Okay this is the part where the lightweight framework comes in. Scrum is not a methodology so even if you follow Scrum step by step you won’t get results. Scrum is simply a framework for doing things. And it is very complementary with other processes techniques, methods, approaches whatever you want to call them. For example I use Design Thinking in combination with Scrum a lot. Rather than provide people with detailed instructions the rules of Scrum Guide their relationships and interactions. Yes so the rules of Scrum, simply is more of a guide, it’s not an instruction. Scrum Theory. Scrum is founded on empiricism and lean thinking. This is very interesting because in the 2020 Scrum Guide the mentioning of lean has become explicit, and in the 2017 guide it was not. It was common sense because Scrum is a practice of both agile and lean. Actually, agile naturally encompasses lean so it’s a lot of common sense that has been built into the official Scrum language now. So empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. It’s all about facts. It is evidence-based management. This is the basis of Scrum. Lean thinking reduces waste and focuses on the essentials. So this is the lean concept of reduction of waste, “muda.”
Scrum in a nutshell. This nutshell description of Scrum is something new in the 2020 Scrum Guide. In a nutshell Scrum requires a Scrum Master to foster an environment where a Product Owner orders the work for a complex problem into a Product Backlog. The Scrum Team turns a selection of the work into an Increment of value during a Sprint. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint. And then you repeat it. So already in this space in this nutshell part you can see Scrum is led by the Product Owner and the Scrum Master, two servant leaders. It’s about creating the environment and helping people realize value within the Scrum framework. And then the last point, the fourth point, the repeat part. This is very important because in agile, iteration, this is really the basis of the activity.
The Scrum framework. Scrum can become overwhelming although it’s a lightweight framework it is rule based so there’s quite a lot of things that we can’t get lost. So the taxonomy. Remember these key headline items. The pillars, the values, the Scrum Team, events and artifacts. And along with artifacts we have the commitments for the artifacts. Again this is something new in the Scrum Guide 2020. There are three pillars. Scrum pillars; transparency, inspection and adaptation. And there are five values; focus, openness, courage, commitment and respect. There are three accountabilities in the Scrum Team; the Developers, the Product Owner and the Scrum Master. And then there are five events in Scrum. The Sprint itself, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. There are three artifacts; the Product Backlog, the Sprint Backlog and Increment. Yes an “Increment” is an artifact. We’ll get to that. And each of these artifacts, Scrum Guide 2020 has made it explicit what the commitments are. So the commitment of a Product Backlog is the Product Goal, the commitment of the Sprint Backlog is a Sprint Goal, and the commitment of the Increment is Definition of Done. I actually would like to add “rules” back into the Scrum framework, although in the 2017 Guide it was a little bit more explicit and less on the 2020 guide. I find that, Scrum, since it’s like a game, and every game has a rule, it’s good to have the rule mindset. Because it’s very easy to organize the thoughts. So I’m just going to put it here.
The Scrum pillars. The three pillars. Actually it’s the three pillars of empiricism. Transparency, inspection, adaptation. These are the three Scrum pillars of empiricism. Empiricism means working in a fact-based, experience based and evidence-based manner. Progress is based on observations of reality, not fictitious plans, so not about predictions. It’s about measured evidence things that you can even measure the value. Transparency. Transparency means making the emergent process and work visible. We all know what’s going on. Inspect Scrum artifacts and progress toward goals frequently and diligently. Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change. So check your work as you do it. And then last one adaptation. Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. Adaptation becomes more difficult when the people involved are not empowered or self-managing. Note that the language has changed from self-organize to self-manage. This is a change in Scrum Guide 2020. A Scrum Team is expected to adapt the moment it learns anything new through inspection. Adaptation. It’s okay to change tactical direction once we have new information.
The first Scrum value is Focus. Without the Scrum values and the focus we would be just going through the motions of Scrum. We focus on having a Done “Increment” at least by the end of every Sprint. It’s important to close every Sprint and the important thing here is to deliver a Done Increment. The Scrum events and artifacts help create focus on inspecting progress and new information. This new information part it sounds a little bit obvious but we often overlook it, because we’re so process driven and just following it even if new information comes in we actually don’t activate our curiosity and pick those things up. So in Scrum during the Sprint if new information comes in, it’s a very important thing that we pay attention to, because we need to adapt to new information. We focus on the Sprint Goal to guide the Team and what to deliver. The Product Backlog is an ordered list. The Product Backlog is a list, and that creates focus on what is most important. What is the most important thing to do next? So Product Backlog refinement, prioritization is a very important activity in Scrum. Time-boxed events create a sense of urgency and help us focus on the purpose of the event. Scrum is a time-boxed agile approach. There are other non-time-boxed approaches like “Scrumban” and so on and so forth. In this case Scrum, because we have a fixed Sprint cycle it’s a time-boxed agile approach. The entire Scrum Team is accountable for creating a valuable useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master. So, not “roles” but “accountabilities”. It’s a little bit of a unique way of using the language since in the Scrum Guide. Focus facilitates empiricism and collaborative teamwork instead of people working independently on separate Product Backlog items. Scrum Teams are often more effective when they collaborate on one or two things now during the Sprint. Yes division of labor, each Developer can work on things separately, that’s fine, it’s up to the team’s choice. But meanwhile there is an encouragement to simplify things and work on one thing at a time together, collaboratively. That is an encouragement under the Scrum Guide. The entire Scrum Team’s shared accountability to deliver a valuable useful Increment creates a focus on the overall outcome, not simply on what each individual can accomplish. Yes, so we say there’s no blame culture inside an agile team. In the Scrum Team, no finger pointing because it’s not a responsibility of a single Scrum Team member to deliver something. It’s shared accountability. It’s very important. Having a Product Goal creates focus on where we are going, and that can inform the team’s decision on a daily basis. Yes, daily. Often cases if we take a project approach, we get called into project meetings but then we don’t really work on it until we jump onto that project. In the case of Scrum it’s daily. So we work on a daily iteration. We don’t do context switching, and this continuum, this is a very important part about Scrum and that’s the reason why we do this as Sprints, as a stable team of Developers, Product Owner and Scrum Master. When there are competing priorities, focus helps a team decide what is the most important thing right now. When the future is uncertain, there is a tendency to want to keep analyzing. Analysis paralysis. Focus helps a team accept uncertainty, look at what they know today, and take a small step. It’s volatile, uncertain, complex, ambiguous, and in my case I add “overwhelming”, so VUCAO. We live in this kind of world, so that’s the reason why we experiment and iterate with Scrum. In Scrum you have the thinking time, the Sprint Review the Sprint Retro and then the Sprint Planning, but then during the Sprint you try, the development days, you really try to concentrate on working on all of these things so when something that you don’t know we tend to get stuck but Scrum really encourages to pushing and going into execution during, in between Sprint Planning and Sprint Review. So, we do the “thinking” and the “doing” clean switch. Meanwhile if there is new information that comes in we adapt and that’s how we keep on making things going on in Scrum.
Second one. Scrum values openness. Being open about our work helps create transparency to our progress. Without transparency, any attempts to inspect and adapt will be flawed. Openness facilitates collaborative teamwork: it enables team members to ask for help and offer help to each other. Yes so this is very important. In a traditional hierarchical organization you have a clean “leader-follower” fixed structure. Now in the Scrum Team everybody leads each other and everybody follows each other. So depending on whatever that you’re working on, if you are closest to the information, if you have the knowledge and skills, you lead and then other people follow. And you as a leader you offer help, and as follower you ask for help. That’s how it works. That’s the reason why it’s a self-managed team rather than a hierarchy. Openness enables team members to share their perspectives, feel heard by their peers, and be able to support team decisions. Behavioral aspects of the Scrum Team are very important. Openness facilitates empiricism. When our assumptions turn out to be invalid, openness helps us admit we were wrong and change direction. So persevere, pivot or tweak as in Lean Startup. We don’t have to get stuck if we find new information saying that what we are doing is wrong, our hypothesis is wrong, so in that case you can switch to something else, pivot or tweak. There are built-in mechanisms around this; we will later on talk about the Sprint goal and how and who can stop the Sprint in the worst case, but most likely how we maintain the Sprint Goal and tweak the way we do things so that we will be able to create an Incremental value still while maintaining the Sprint Goal. We’ll talk about this later. Limiting a Sprint to one month or less promotes an openness to changing direction based on new information. In a waterfall project you have 18 months or six months or whatever that waterfall project term is and during that period you can’t really change directions. But in Scrum the Sprints are short, maximum one month and typically two weeks and sometimes even shorter, one week. So we have the ability to keep on making course adjustments continuously. The Sprint Goal is fixed and provides guidance, but the plan for meeting the Sprint Goal is open to change based on what the Developers are learning as they do the work. As I earlier on explained, the Sprint Goal is fixed so what kind of Sprint Goal to set, actually that’s quite an art and that’s one of the practices that you have to really become proficient in Sprint Planning. But yes, you put together a big enough and flexible Sprint Goal that you make adjustments on how to achieve that. But the Sprint Goal itself doesn’t change. A transparent Product Backlog demonstrates openness with our stakeholders about what value is planned for the product (and what is not planned) and what is likely to be next. Transparent Product Backlog; so in a in a physical office setting the Kanban board often is in a place where it’s quite visible and everybody is able to see that and we actually do invite stakeholders to sometimes stop by to see where things are. We don’t need to receive inspections or check-ins from the stakeholders, they can come and go as they wish and take a look. It’s all about transparency and openness and even the Product Backlog is made like that. The Sprint Review demonstrates openness to sharing progress with our stakeholders, as well as openness to feedback and collaboration with them. Sprint Review; it’s the event that we use for creating transparency on where we are and what we are doing and how we are doing it. The Sprint Retrospective’s focus on continuous improvement of our team’s interactions, processes, and tools invites an openness to feedback, reflection, and changing how we work. Yes so this changing part it will tie in next into the courage part.
Courage. Every Scrum Event is an opportunity to inspect and adapt – with courage, we know it’s okay to tweak or pivot. We can change direction regarding what we are building. We can change direction regarding how we are building it. The time-box of a Sprint limits the impact of failure to the length of a Sprint. This gives us courage to try new things, to experiment, to learn. So an 18-month waterfall might cost you one million dollars or two million dollars, but if you break it up into two week Sprints it might just cost ten thousand dollars compared to a one million dollar loss. It’s a very small percentage and that gives you courage to try to do trial and error. The Product Owner is accountable for maximizing the value of the product, so she can demonstrate courage by saying “no” to low value features. The Developers are accountable for instilling quality by adhering to a Definition of Done, so they can demonstrate courage by saying “no” to cutting quality under pressure. The courage to say no. It takes courage to be transparent about progress under pressure to deliver faster. Deadlines, it’s something that we almost dogmatically feel that we have to meet. But it does take courage to be transparent about progress. Don’t develop the wrong thing just for the sake of meeting deadlines, that’s courage. It takes courage to NOT show our stakeholders undone work. The Scrum rule of Definition of Done; you cannot call anything an Increment unless it meets the Definition of Done. You cannot release an Increment unless it’s Done. It takes courage to ask for help or admit we do not know how to do something. That’s the reason why a Scrum Team is cross-functional so we can help each other, ask each other and as a matter of fact even outside of the Scrum Team, the use of subject matter experts. These are things that are integral to the openness and courage of the Scrum values. It takes courage to hold others accountable when they are not meeting commitments to the team. If you see somebody not doing something, sometimes we withhold, we become, in the language of Radical Candor we become “ruinously empathetic”. We need to speak up when we see that somebody is not upholding their accountability. It takes courage. We may discover we built something our customers don’t want. It takes courage to admit our assumptions were wrong and change direction. Pivoting and tweaking. It takes courage to try to build something we’ve never built before, not knowing if it will work or not. Yes, Scrum allows you to explore; it’s very important for innovation. It takes courage to share a dissenting opinion with a team member and engage in productive conflict. This is a high order teamwork challenge, and as a behavioral coach it’s probably a good chunk of the coaching work that I spend time with the teams. Differing opinions, hearing each other out, suspending your assumptions, really have a shared understanding even if you have differing opinions, and most importantly the ability to come to an agreement. “I still believe this, but as a team we’ve decided to go for this hypothesis, therefore I support.” It’s very important that for everybody to have the courage to be able to accept doing something that even if you don’t completely agree to, but as a team you support.
Commitment. Commitment in Scrum is not a promise to deliver a set scope by a set date. Nope, that’s not the target. Meeting the deadline, that is not the target. Checkbox exercises, that is not the target. We commit to the success of the team. It’s very “outcome’ driven. It’s not just about getting things done for the sake of getting things done. Success is what we are going after. We commit to doing Scrum fully, not just picking and choosing the easy parts. So a lot of failures of product development that tries to do Scrum, is because it becomes “scrummy”, because of “pick and choose” scrum. There’s a reason why Scrum is a framework because all of the individual elements, components of Scrum are complementary to each other. So if you take out any part of that and try to do Scrum, it doesn’t generally work. So stick to Scrum. That’s the commitment. We commit to continuous improvement and the courage to tweak and pivot based on new information or empirical data. We cannot predict or control all of the complexities in product development, but we can commit to taking actions and adjusting our behaviors based on feedback and new learnings. It’s impossible to predict the future, and in a complex adaptive product development, it’s impossible to have a complete upfront understanding of the customer. Through trial and error is the only way that we can find out about what the customer wants, so we can take actions to get closer to that because we listen and we take in new information. That’s the whole point about Scrum. It’s our ability to understand what we have control over, what we do and how we do things, and things that we don’t have control over. All the complexities in product development as I say, yes separate that. We commit to delivering value. The Product Owner demonstrates commitment by making the best decisions to optimize the value of the product, not simply trying to please every stakeholder. It’s about value. This is not about pleasing internal stakeholders. It’s not about going through the motions. It’s about success. The Developers demonstrate commitment by creating an Increment that meets their definition of “Done,” not something that is almost done. Almost done is not done. The Scrum Master demonstrates commitment by upholding the Scrum Framework. We commit to delivering a “Done” increment. Commitment to the Product Backlog, is a commitment to transparency. Commitment to the Sprint Backlog, is a commitment to transparency of our progress. Commitment to the Daily Scrum, is an opportunity for the Developers to demonstrate commitment to each other. Daily Scrum; later on we will talk about that. It’s 15 minutes, fixed time, fixed place, and you commit to making it to the daily stand up and you commit not being late and you commit to finish it within 15 minutes. Very important because it’s a commitment to each other; you make yourself predictable through this kind of commitment and that really makes teamwork strong. And then finally commitment to the Sprint Retrospective, it’s a commitment to continuous improvement as a team. Again a very strong lean concept embedded inside Scrum.
Scrum values, respect. By respecting that people are naturally resourceful, creative, and capable of collaboratively solving complex problems, we empower and enable self-managing teams. People are naturally resourceful, let’s believe in that. That’s the respect. When we respect that people are motivated by autonomy, mastery, and purpose, we create an environment that engages people and enables teams to become greater than the sum of their parts. Yes this completely ties into motivation theory, for example scholars like Maslow, hierarchy of needs; self-actualization, this is professional mastery, self-transcendence, this is about doing good for the collective good, for the whole. Scrum is about creating an environment to bring out these beautiful motivations out of people. When there is respect for all opinions and perspectives, we can ensure everyone has the opportunity to be heard. When we feel we have been heard, it is possible to fully support team decisions even if the decision was not our preference. So I already spoke about this, again it’s super important that we as a team develop this ability to support team decisions even if this decision individually was not our preference. And the precondition to that is that everybody has been heard. The Scrum Team is cross-functional, which means as a whole it has all of the skills necessary to deliver a usable product Increment. This promotes respect for everyone’s experiences, skills, and ideas, and promotes learning and growth. From the practicing Scrum part, in the team formation part, it becomes a big question often “do we need to have all of these people who have all of the complete skills?” Truth is that you need to have a cross-functional team of “learners” because there’s no way that we can know everything. But if you have a team of good learners and diverse abilities of learning different things, each individual will be able to tap inside and outside the Scrum Team’s knowledge and that’s how we work and that’s what we mean as the Scrum Team as a whole has all the necessary skills to deliver. The Sprint Backlog is owned by the Developers. This one you need to remember the Sprint Backlog is owned by the Developers. Respect that the Developers decide how much they can do in the Sprint and how to do the work. Later on we will touch on this again, it’s up to the Developers to decide what to do, how to do, and how much to do. By only reviewing product Increment that meets the Definition of Done in a Sprint Review, we bring transparency to our true progress. This demonstrates respect for our stakeholders. Do not deliver crap unfinished, flimsy stuff. Only verified with the Definition of Done completed work. It’s the discipline. That’s how we quality control in Scrum. The Product Owner seeks input from, collaborates with, and sets realistic expectations for stakeholders. This is another demonstration of respect for stakeholders. This is another demonstration of respect for stakeholders. The Scrum Master’s focus is on the health of the Scrum Team and the effective use of Scrum. Having a role that focuses on teaching, facilitating, and coaching demonstrates a respect for people and teams and their capacity for growth. A Scrum Master teaches, facilitates, and coaches. Scrum’s focus on delivering value shows respect to our organization by not spending money on low value features or things that may never be used. Having a usable Increment of value by the end of the Sprint shows respect to our organization by not forcing more investment to realize value. It gives the organization the flexibility to make investment decisions. In waterfall, often cases investment money goes to waste because it’s a fixed deterministic process and you have to finish it and therefore even if you start having the gut feeling that people might not use it, because of your organizational mandate, you do need to complete it. In Scrum you don’t have to complete it if it’s the wrong thing, if you have evidence that’s the wrong thing to develop. That way you save the money and that’s the respect that you pay to your sponsors. You don’t waste their money. Meanwhile if you finished it early, that’s also respect there. You move on to the next value item and again this is about investment optimization, helping your stakeholders, your sponsors. That’s respect. That’s the Scrum values.
One of the best ways to visualize the Scrum Team is the Viking boat, I really like this analogy. You have the Scrum Team which is the entire boat, and inside the Scrum Team you have the Developers, you have the Product Owner, and you have the Scrum Master. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Note that the Developers used to be called Development Team. It’s a change now. Previously the Scrum Team had the Development Team and the Scrum Master and Product Owner, so there was a little bit of a feeling of a divide between the Scrum Master and Product Owner, versus the Development Team. No more. The Scrum Team, inside there is the Developers and the Scrum Master and the Product Owner. So from a Venn diagram perspective, there were two circles, now there’s just one big circle. Within the Scrum Team, which is typically 10 or fewer people, there are no sub-teams or hierarchies. This is another interesting one, ten or fewer people. In Scrum Guide 2017, it was up to nine Development Team members excluding the Product Owner and the Scrum Master, so technically in the old Scrum Guide the Scrum Team could have been up to 11 members if the Product Owner and the Scrum Master was not a Developer. So now it’s a slight reduction because it’s now up to 10 people for the whole thing. Personally I like to stick to Miller’s magic number seven plus minus two. This is a 1956 concept from a cognitive psychologist called George Miller and I think you’ll agree that seven plus minus two, so five to nine people, this is probably the most comfortable and natural size for us when we group and organize. So seven plus minus two, it correlates with the maximum ten people in the Scrum Team. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. There’s no separate manager. They just self-manage. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Developers are the people in the Scrum Team that are committed to creating any aspect of a usable increment each Sprint and are accountable for instilling quality by adhering to a Definition of Done. Scrum across the years have become increasingly popular with non-programming teams, non-IT teams, so the Scrum language has been evolving to be encompassing of any type of Scrum Team. That’s the reason why the Developers are not just software developers. Developers are anybody that is committed to creating any aspect of value, a usable Increment of value. Product Owner. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Maximizing the value of the product resulting from the work of the Scrum Team. It’s a very outcome, product value focus. It’s not about the Product Owner having a specific type of activity. Try to sense this nuance here. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is an evangelist. Not only just taking care of the Scrum Team, but also for the wider organization. Scrum does not specify these roles as being full time, part time, etc. It is left out on purpose. This is a note that I personally put in because often cases there’s a discussion about do we need to have a dedicated Scrum Team. Well, the Scrum Guide does not answer that. We have to use our business judgment, common sense as well. So yes, it is possible to have a Scrum Team where people are part-time. But we do need to have to make pragmatic considerations against that because even if it’s a part-time team, you still have to do your daily stand-ups, you still have to maintain all of the commitments that have been outlined in the Scrum Guide.
So why do we work as a Scrum Team? Well, if we are team with no Developers, we’re not going to go anywhere. If you are a team with no Product Owner, nobody telling us which direction, nobody’s showing us the north star, we’ll go all over the place, we’ll be lost. It’s such a waste. If you’re a team with no Scrum Master, no one to teach us how to ride this complex adaptive boat, we might hit rough waters, shallow stones, rocks and we might not make it to our destination. So we need to have a good Scrum Master that will guide us on how to run our boat. So finally if it’s a full Scrum Team, we will be able to make the most efficient way of passage in our journey to reach our destination, our final Product Goal.
Developers. Let’s look at each of the roles from here. Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for: Creating a plan for the Sprint, the Sprint Backlog. The Sprint Backlog is a plan for the Sprint and the Developers are accountable for that. Instilling quality by adhering to a Definition of Done. DoD, Definition of Done, is a quality control mechanism and we abide to that and the Developers are accountable for that. Adapting their plan each day toward the Sprint Goal; and, holding each other accountable as professionals. Each day, professionalism, every day, yes Scrum is a daily activity.
The evolutionary path of the Developers. I just love this visual. In 1965 psychologist Bruce Tuckman came up with a model of five stages of group development: forming, storming, norming, performing and then adjourning. In fact in Scrum you see this clear pattern and it’s really the Scrum Master’s job to help coach the team to go through this process effectively. And it’s no easy feat even for a professional behavioral coach like me. So in the beginning you group and then you have your storming phase. During the storming phase you have a temporary reduction in productivity; it’s called the j-curve effect or the hockey stick. So be prepared once you form; there will be a storming phase and it will be a little bit chaotic, but persevere and carry on. Every Scrum Team in the beginning will go through this temporary loss of productivity. It’s necessary; that’s how we group. And then the team will start forming. When it forms it can form nice and cozy, acting like a family. That’s really good. Sometimes the team temperature is low so they will norm not as strong, but if you’re a family, that’s not bad. But the best type of teams, the most high performing teams act like a wolfpack. Everybody is driven, everybody is really going after something. So when you become a Scrum Team, when you go through your forming, storming, norming, and performing stages, really try to form and norm at this very high performance level. Try to become a wolfpack.
Product Owner. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is also accountable for effective Product Backlog management, which includes; so the Product Backlog, this is owned by the Product Owner and the Product Owner is accountable for maintaining the Product Backlog, Developing and explicitly communicating the Product Goal; creating and clearly communicating Product Backlog items; ordering Product Backlog items; and, ensuring that the Product Backlog is transparent, visible and understood. The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable. In real practice, the Product Owner of course will be involving the Developers in building the Product Backlog because the Product Owner needs information the Developers are most akin to knowing both the what and the how, so their information is most important, and often cases the Product Owner will delegate populating the Product Backlog and prioritizing it, but at the end of the day it is the accountability of the Product Owner for all of these things even if he has the help from the Developers. For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review. It’s often the case that the Product Owner is simply a proxy and although the Product Owner is responsible for a development of a specific product line, often the Product Owner does not have the full power of launching it and investing in a very flexible way of growing that product. This is a very sad phenomena that happens often in large organizations, so explicitly, the entire organization must respect the Product Owner. If we’re going to empower the Product Owner, give the Product Owner power. The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner. There’s only one Product Owner, there’s only one owner. If there are a lot of people, ownership is dispersed so we only want to have one Product Owner, and really give the Product Owner ownership of the product please.
The evolutionary path of the Product Owner. I can’t emphasize enough that if the Product Owner acts like a boss in the old “leader-follower” way, the Scrum Team will fail. Or if the Product Owner just acts like a middle manager passing on instructions from above, the Developers won’t take the Product Owner seriously. So don’t be just a scribe or a proxy. At least be a good business representative that’s an effective voice of the customers and stakeholders. But even more powerful is if the Product Owner can be a sponsor of the Scrum Team’s endeavor, and ultimately I coach Product Owners to try to see the Scrum as a startup enterprise, and that the Product Owner himself as a startup entrepreneur driving this startup business. This is going to be the most powerful type of Product Owners. So, Product Owners that are super weak simply being a scribe and a proxy is not good enough. And then the wrong type of Product Owner, a Product Owner that acts like a boss instructing, that kind of role does not exist in Scrum. Default, at least representing the business interest of various stakeholders, customers and so on, so somebody that is very balanced and is able to communicate that. But even better is a sponsor and an entrepreneur. Product Owners are really important; often cases it becomes the make it or break it point. The power of the drive of the Scrum Team really depends on the Product Owner.
Scrum Master. Understandably Scrum Master has a big role to play in Scrum, so this slide is going to be loaded, it’s going to be very long, hang on with me. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework. Scrum Masters are true leaders who serve the Scrum Team and the larger organization. Note the word “serve” together with “leader”. Servant leader. The Scrum Master serves the Scrum Team in several ways, including: coaching the team members in self-management and cross-functionality; helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done; so, making sure that people follow the discipline; causing the removal of impediments, so blockers to the Scrum Team’s progress, “causing the removal”, sometimes the Scrum Master himself won’t be able to remove it, but he will be able to instigate actions that will make the removal happen. Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox. So this is a part about it’s not managing, it’s ensuring. So Scrum Masters coaches. Makes sure that these events are done properly, but it’s not the Scrum Master’s job to manage and organize all of these events and so on and so forth. No that self-managing part is the Scrum Team’s. The Scrum Master serves the Product Owner in several ways, including: helping find techniques for effective Product Goal definition and Product Backlog management. A Product Goal is very difficult. Managing the Product Backlog takes experience, there is a technical, technique element too, so the Scrum Master will really help the Product Owner on these two fronts. Helping the Scrum Team understand the need for clear and concise Product Backlog items; clear and concise, because remember the Product Backlog is a list, it’s an ordered list. Helping establish empirical product planning for a complex environment; again, empirical process control. Facilitating stakeholder collaboration as requested or needed. And the Scrum Master serves the organization in several ways, including; so remember this – the Scrum Master serves the Scrum Team, the Product Owner and the entire organization. Leading, training, and coaching the organization in its Scrum adoption; so evangelizing. Planning and advising Scrum implementations within the organization; so synchronizing, integrating. Helping employees and stakeholders understand and enact an empirical approach for complex work; waterfall is predictive planning so you predict the future 18 months later, but meanwhile the spirit of agile is really evidence-based, so where we can the Scrum Master tries to start instigating the culture of evidence-based management, empiricism, even outside of the Scrum Team. Removing barriers between stakeholders and Scrum Teams. Communication. Impediments, let’s remove that. No barriers.
The evolutionary path of the Scrum Master. Again, the Scrum Master is not a manager. Understandably this is one of the biggest behavioral change struggles that former project managers struggle in becoming a Scrum Master. Actually, many project managers don’t recognize that a Scrum Master is quite a different job. Because, again, Scrum Master is not a manager, remember that. So, Scrum Masters, don’t be just a clerk, never be a puppet master, dishing out do this do that instructions, and get out of the job of being an organizer for the Scrum Team. You’re not a manager, so be a coach, advisor, and an expert on how to do Scrum.
Let’s start with the Sprint. Often overlooked, but the Sprint is itself an event in the Scrum framework. It is a container event for all other events. Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. What is this saying? Couple things; number one, it is saying that a Sprint is maximum one month – in practice typically it’s two weeks, sometimes even shorter, one week. The second thing is that after Sprint Review and Sprint Retro finishes, the next Sprint immediately starts, so you immediately go into Sprint Planning. Now in practical terms, most last day of Sprints happen on Friday, so you get the weekend off and then you have a fresh start on Monday okay. It’s simply a matter of business days, a continuous way of doing things. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints. Again, Scrum Sprint is a container event. During the Sprint: no changes are made that would endanger the Sprint Goal, quality does not decrease, the Product Backlog is refined as needed, and, scope may be clarified and renegotiated with the Product Owner as more is learned. After Spring Planning and the Sprint Goal is fixed, you go into doing mode. So, while you do adapt the plan during the Sprint, such as refining the Product Backlog as needed and clarifying and renegotiating the scope with the Product Owner, that doesn’t mean you get to make changes of magnitude that will effect the Sprint Goal. That’s part where it says no changes are made that would endanger the Sprint Goal during the Sprint. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. Again maximum of one month, and if it’s two week Sprints, this ensuring inspection and adaptation of progress toward a Product Goal is within two weeks. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project. So, Scrum does use the “project” language, if you want. But it’s not a waterfall project, it’s not 18 months, it’s a two-week project, that’s the important part, or one month depending on your cadence of your Sprint. A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint. This is a really important point and actually a very rare point. I actually have not experienced a Sprint being cancelled because of the Sprint Goal becoming obsolete. It’s a very rare thing but it can happen. Sometimes you’re developing a product, a feature, a function, and because of external events all of a sudden that is no longer in the need, there’s no more market need. Well if you continue developing the product just for the sake of completing it, that’s complete waste. That’s the reason why we do have the ability to cancel a Sprint, because that’s reality too.
Sprint Planning. Sprint Planning is a big event, it’s a maximum of eight hours for one month Sprints and for two week Sprints, it’s typically four hours. So it’s a heavy event. Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is done by the entire Scrum Team. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice. Again, it’s the Product Owner that’s going to ensure Sprint planning takes place, is done properly. Typically Sprint Planning is done only with the Scrum Team, but if there is a need for a subject matter expert, there is a need for certain types of mission critical input, exceptionally you can invite other people outside of the Scrum Team to join the Sprint Planning. Sprint Planning addresses the following topics. So this is something that is new to Scrum Guide 2020. They became a little bit more clarifying on how to do Sprint Planning because as you can see an eight hour event is actually quite big. Topic one: why is this Sprint valuable? The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning. Topic Two: What can be Done this Sprint? Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence. So you can do Backlog refinement in Sprint Planning because it’s an ongoing process, but do come with a refined Backlog. If you come with a messy Product Backlog, it will add time to Sprint Planning. In selecting how much can be completed within a Sprint, the Developers forecast the Sprint by considering their past performance, their upcoming capacity, and their Definition of Done. It’s the Developers who will be deciding how much work that can be done and selecting what work, it’s up to the Developer’s flexibility for deciding how to develop that particular Increment. Topic Three: How will the chosen work get done? For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value. It’s up to the Developers on how to develop that Increment. Also notice this “decomposing Product Backlog.” Later on after Scrum theory, I would be talking about Scrum practices and often a practice in Scrum is grouping tasks into “stories”, and grouping stories into “epics”. So there you break it down into smaller pieces so the Backlog is not just a long list of tasks, but it’s broken down of something of a higher objective. This is a technique that we practice in Scrum.
Daily Scrum. The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. Take note, it’s not for the Scrum Team, it’s for the Developers. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. The Product Owner and the Scrum Master can join if they are Developers themselves. They actively join. But if they are not Developers, they are just Product Owners and Scrum Masters, they let the Developers self-manage the daily stand-up. And the daily stand-up needs to be exactly at the same time. A technique that I often use is that instead of saying 8:45 to 9:00am for the daily stand-up, use an odd time like 8:43 to 8:58am. That way people will make sure that they are there and start promptly on time. And use other ways of making sure that everybody will go through the daily stand-up every day at the same time. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. You probably already know that often cases Daily Scrums, daily stand-ups are done in the form of what I did yesterday, what I plan to do today, and what impediments there are. It’s a good practice but you don’t have to do it that way. Scrum Guide is very explicit about that part – you can be creative and adjust it to your team’s reality. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. So, sync-up meetings, no need. Just do it on the daily stand-up and keep it 15 minutes, and then spend the rest of the time, the team will probably meet together during the day for other purposes, just focus on particular contents, particular activities and for the syncing up just use the daily stand-up. It removes the need for those kind of coordination meetings. The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.
Sprint Review. Day 1 Sprint Planning, then day 2, 3, 4, 5, 6, 7, 8, 9 development, day 10 Sprint Review, Sprint Retrospective. Sprint Review. The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. Inspect, determine, present, discuss. Note that it’s not just demoing. It’s beyond presenting, you do discussions, you do deciding, you do inspection. Sprint Review is for that purpose. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation. It’s a working session. Attendees collaborate on what to do next. You have your stakeholders, sometimes your customers involved. Collaborate with them. It’s a working session with them. This is not just a demo day. The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. It is again still a heavy meeting, for a one month Sprint it’s a half a day event; for two weeks Sprints it’s still around two hours. So it’s fairly heavy. Definitely Sprint Reviews in one hour is a bit short, a bit light. You can’t go deep in the inspecting and the discussion and the deciding parts. You would really want to get inputs. This is an opportunity for stakeholders to make requests for the next iteration of features, functions etc. So make sure that you allocate sufficient time for Sprint Review.
Finally, Sprint Retrospective. The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Sprint Review is the end of Sprint “what” meeting. The Sprint Retrospective is the end of Sprint “how” meeting. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. If the Definition of Done was loose or was not functioning, talk about that. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. So be very exploratory and tangible. Work on real problems that you are encountering. Celebrate the things that have been going well, and even better, if things you have been able to fix, celebrate that too, recognize that too. The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint. Okay, this is a change from Scrum Guide 2017. In the Scrum Guide 2017, it was mandatory to select at least one Product Backlog item for improving the “how”. In the 2020 Scrum Guide, it became less prescriptive, so now it’s a choice. Nonetheless it’s still very encouraged to find at least one improvement item on interactions, processes, tools etc. So, it’s still encouraged but no longer mandatory. Careful on this on the certification exam. The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one month Sprint. For shorter Sprints, the event is usually shorter. So, for a two week Sprint, usually it’s about 90 minutes.
Scrum artifacts. Scrum’s artifacts represent work or value. It’s work, or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation. So it needs to be transparent, it needs to be consistently communicated. Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured. These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders. So these are the artifacts and there are three of them. Let’s start with the Product Backlog. The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Quite a few things here. First it’s a list and it’s ordered and the nature of this list is that it is emergent; as new information comes in, the Product Backlog grows. And it’s about what is needed to improve the product. It’s about improvement. It’s a single source of work, so anything that you are developing for this product if it’s not on the Product Backlog, something’s wrong. So make sure it’s captured on the Product Backlog. Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. So if there is a big Product Backlog item, you’ve got to break it down and fit it into one Sprint. Then it’s ready for selection. They usually acquire this degree of transparency after refining activities. What is refining? Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work. Again the Scrum Guide is trying to be as accommodating as possible for non-software development type of applications of Scrum. The Developers who will be doing the work are responsible for the sizing. Sizing, yes. The Product Owner may influence the Developers by helping them understand and select trade-offs. We’ll look at sizing later on in the Scrum practicing part. The Product Goal is the commitment for the Product Backlog. The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is inside, in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal. So the Product Goal is literally the goal. It’s the future state, your vision of what you want to build, what you want to develop. A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract. This is a very powerful definition; a product is a vehicle to deliver value, and therefore it can be a service because it doesn’t have to be a physical thing. And as a matter of fact I am in Organization Development, OD, sometimes I do full organization interventions and in those things I see the organization as a vehicle to deliver value. There’s complete truth in that. In this case, in Organization Development, the organization itself is the product. It has clear boundaries, has known stakeholders, and it has well defined users or customers. A company, an organization, often can be seen as a whole product. So you can do Scrum on Organization Development. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next. One at a time.
Product Backlog, Sprint Backlog. The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). The Sprints Backlog is a subset of the Product Backlog and it is very action oriented, why what and how. The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum. While the spirit of Sprint Planning is to plan out for the whole two weeks, if it’s a two-week Sprint, as you develop it there is always going to be the possibility of learning new things. For example, you do a customer testing and something comes out. You are developing a certain type of technology, and you find a better technology. Things like that. If that is the case, as long as the Sprint Goal stays stable, you have the ability to adapt the Sprint Backlog. The Sprint Goal is the commitment for the Sprint Backlog. The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. This is the key thing. The Sprint Goal is fixed, it’s stable. But how to achieve that Sprint Goal, Developers have the full freedom. You may adapt. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. Because everybody is unified under the Sprint Goal, that’s the key thing. The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal. So Sprint Goal stays, but the scope of the work can change.
Finally, an interesting concept: yes, an Increment is an artifact. An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. Evidence-based management. Increments: if it clears the definition of done, there is a correct testing criteria, a verifying criteria that it creates value. That’s the reason why it supports empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value. So, using the word gate, a gateway, this is waterfall language. There is often confusion that the Sprinter Review is like a waterfall release event. No, it’s really up to the Product Owner to decide whether or not to release an Increment. And you’re okay to do that even before Sprint Review. Definition of Done is the commitment for the Increment. The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. Work cannot be considered part of an Increment unless it meets the Definition of Done. The moment a Product Backlog item meets the Definition of Done, an Increment is born. For all artifacts, the Scrum Guide 2020 has made it explicit that they are paired with a commitment: Product Backlog has Product Goal as this commitment, Sprint Backlog has Sprint Goal as its commitment, and for the Increment the commitment is Definition of Done. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. Remember the courage part; yes, you need to have the courage to not deliver unfinished work. Definition of Done, very important here. If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product. This will show up in the certification exam so take note. Who decides the Definition of Done: if it already exists in the organization, you got to follow that. If not, it’s the Scrum Team that creates the Definition of Done. Remember that the Scrum Team is the Developers, Product Owner and the Scrum Master all together. The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done. Although in this Scrum crash course I won’t be covering Scrum at scale, scaled Scrum, it is part of your certification process so you will have to do some individual reading on that part. But in that, what it explains is that you will be having a situation where multiple Scrum Teams share one Product Backlog. In that case the Definition of Done needs to be absolutely consistent so this is what it is talking about. All of the Scrum Teams need to mutually define and comply with that consensus Definition of Done.
Last piece of the Scrum framework. The Scrum rules. the Scrum rules aren’t really explicitly mentioned or defined in the Scrum Guide 2020 so it’s often overlooked as not part of the framework but it is very important.
In the Scrum Guide 2017 the Scrum rules was explicitly explained. It went as following: The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of the Scrum Guide. So the Scrum Guide itself is the Scrum rules, that’s what Scrum Guide 2017 was saying. In Scrum Guide 2020 that line has been removed so it’s not as obvious. Nonetheless if you look at the title of the Scrum Guide, it goes “The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game”. So Scrum rules are still there so please take note of that. That’s the reason why I decided to include it back into one of the important elements, as a matter of fact, it’s the whole thing of the Scrum framework. Then there are a couple other things. First, specific tactics for using the Scrum framework vary and are described elsewhere. There’s this concept called ScrumAnd. Scrum uses many complementary practices and I will be describing that in the next section, Scrum practices. But within Scrum theory, many of these practices are not explained. It’s not part of the Scrum rules, so take note of that. What’s inside the Scrum rules, Scrum Guide, and many other things that we actually do in Scrum but defined elsewhere; separate those two things. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety. You can do just daily stand-ups, you can just do Sprints, but unless you do Scrum as a whole following the full rules, you cannot call it Scrum. It might be “scrummy” and it might still work, but not as powerful and functional as Scrum. So, if you’re going to do Scrum, do it properly. Notice that Scrum is capital “S” Scrum, and to do capital “S” Scrum, you have to follow the Scrum rules. Lastly, Scrum exists only in its entirety and functions well as a container for other techniques, methodologies and practices. So it’s the same as the last line of Scrum Guide 2017, “Specific tactics for using the Scrum framework very and are described elsewhere.” So there’s the concept called ScrumBut and ScrumAnd: ScrumBut is modified scrum. “We do scrum, but we don’t do this part.” That’s no longer Scrum. It might be scrummy, but not Scrum. So you can’t call it Scrum. Then ScrumAnd. Scrum AND other practices; for example I combine Scrum with Design Thinking, but I still follow the very strict Scrum rules. So in this case, is Scrum AND Design Thinking. So ScrumBut, NO, ScrumAnd, YES.
That concludes Scrum theory. We will very briefly talk about Scrum practices now, and then after that we’ll talk a little bit about the certification process particularly with Scrum.org. Now let’s talk about practicing Scrum; the additional tools, the things that are not necessarily defined and made mandatory in the Scrum Guide that we actually use as Scrum practices.
Quick summary, Sprint, how it works: if it’s a Monday to the following Friday two-week Sprint, Monday is going to be Sprint Planning. Before Sprint Planning, make sure that your Product Backlog is already refined, otherwise you’ll be spending a lot of extra time on Sprint Planning and getting your Sprint Backlog in order, instead of discussing more contents, more understanding of what you can do in this current Sprint. Once you have your Sprint Backlog ready, Sprint Goal is defined, you’re ready, you will start your doing your Sprint development. Developments are going to be from the second day, third, fourth, fifth, sixth, seventh, eighth and ninth day, and each day you will do a Daily Scrum. It’s 15 minutes. Now of course you don’t just do Daily Scrum, you actually do the development so you’ll be spending a lot of time individually and collaboratively, most likely even more collaboratively because Scrum is meant for collaboration. Those will continue for eight days. And the final tenth day is the Sprint Review and the Sprint Retro, and then you close the Sprint. Celebrate, learn, recognize and then you open up the next Sprint immediately afterwards. So this is the cadence. So far this is still within Scrum rules.
Therefore if you visualize it, this is how it’s going to look. You have your Backlog, to be more precise it’s your Product Backlog and your Sprint Backlog. Sprint Planning, then you have your Daily Scrum, then you have your Sprint Review and Sprint Retrospective, and that concludes the Sprint. You immediately go into the next Sprint. This is a visualization; still within the Scrum theory.
Now this is an example of what is a Scrum practice and is not necessarily something that is mandated inside the Scrum Guide. The Scrum Guide does talk about ordering the Product Backlog and making big items smaller and fitting Backlog items that can fit in one day to be ready to be picked into the Sprint Backlog, so it does talk about that. In practice we use jargons like “epic,” “story” and “task.” This is not defined in the Scrum Guide but it is a practice and a common language that we use. The smallest unit of work is a task, a collection of tasks is the stories, the collection of stories is the epic. This is this is how we group, group, group, and it’s a very smart way of controlling very complex big item of things into executable chunks of work. And then we also have another great tool called user stories: as a user, I want to do whatever whatever, so that whatever whatever values are realized. This is a very good way of writing stories, and once you have that as your target, breaking that into task becomes much easier.
Sizing. That is something that has been mentioned in the Scrum theory, the Scrum Guide. Now how do you actually do that? A good practice is called estimation with story points, but it’s not mandatory. It’s a quite difficult technique because in the very beginning when you don’t have data of the productivity of the team it’s very difficult to estimate the story points. What is a good story point? Because everything is relative there, so typically teams will first have to start with sizing with how much time it’s going to take, and then later on when they are able to start seeing that their productivity is increasing, i.e. they get to do more work in one unit of time, then they start using story points; instead of using time they use story points. Story points are shown in the form of difficulty, and if you can do more difficult work in a shorter, less amount of time, that’s a productivity increase. That’s the reason why you use story points. It’s a difficult practice. This is something that it’s hard to explain about but easy once you start practicing and getting hang of it, it’s easy to follow. Planning Poker using a modified Fibonacci sequence, that again is another practice that we use in estimating PBIs, Product Backlog Items with story points. T-shirt sizes are another great way of doing that.
Burn down chart. There is no mentioning of the word velocity inside the Scrum Guide, but in Scrum practice we do use velocity. Is the team speeding up? What does speeding up mean? It means the team is becoming more productive. It means that the team – at a fixed time – you only have two weeks and that is a fixed time; eight hours a day times ten business days, that’s 80 hours per person. And time doesn’t stretch or shrink. So within that 80 hours per person times whatever number of Developers, the total amount of time that you can do as a team is finite. If you can do more work inside in within that fixed amount of time, your productivity is improving. How do you capture that? That’s often by using a burndown chart so you are capturing how much story points you have been able to take care of, execute, deliver, with the Definition of Done, in the Increments that you deliver. And then you measure that against your estimated burndown and your actual burndown, and you keep on seeing if your velocity is increasing. Any given unit of time, have we been able to do more story points? So you keep on challenging every Sprint, every Sprint to do more story points. Sprint 10 was 80 story points as a team, Sprint 11 we challenged ourselves to do 85 and we estimated for 85. But we were able to do 87. Great, you overachieved. So with that in mind, Sprint 12 we decided to go for 90 story points. This time we only were able to do 89 story points but getting closer to that. This is how you measure your velocity, your productivity, and that’s what we use the burn down charts for.
Kanban board. So, the Product Backlog and the Sprint Backlog needs to be visualized and ordered and needs to be in a list format. “Kanban” comes from lean. It’s Japanese, it literally means board. So it’s a visualized board. It started from a Toyota factory and it’s a way of communicating where everybody’s work is. So, it’s a communication board. Typically it’s done in the fashion of “to do,” “work in progress,” and “done.” Now this is the Sprint Backlog, current stuff. What’s unique of the Kanban board used in Scrum is that the Backlog, the Product Backlog, is added to it. So, you have the Sprint Backlog and the Product Backlog in the same Kanban board. It’s a big Kanban board. Often cases this combination is called the Scrum board. Again, that’s something not defined in the Scrum Guide but it’s a common practice.
The Kanban board is used in many ways. You modify it according to your needs. Often cases in teams that I’ve seen we’ve used the concept of triages. So, we have a triage box. Why? During the Sprint, two weeks, the Developers are often interfered, the Product Owner is often interfered by additional requests for work; “Can you add this feature?” “Can you do an emergency work on this function?” “This client needs this and that” and so on and so forth. In organizational power play, if it comes from a senior person the tendency is to accommodate that. But that is breaking Sprint Planning, because that was unplanned work. So, first put it into the triage and the Product Owner will be inspecting it, and whoever outside who is requesting it can negotiate with the Product Owner. “That still is valid for your Sprint Goal and it’s going to realize the Sprint Goal with higher achievement, higher outcomes, so can you prioritize this?” And if the Product Owner agrees it goes from “triage” into “to do.” And because you have limited capacity something has to come out from “to do”, and something goes into “bump.” This is how you can use a modified Kanban board. Another great practice.
Product Backlog building. Just a really quick guide because, practical, pragmatic, because building the Product Backlog is one of the most daunting first things and it can take a lot of time. First, define the Product Goal. You have your Scrum Team name, put it in there, and define your Product Goal. This is your north star; we want to develop a solution that will whatever whatever. Our Scrum Team’s purpose is to build whatever product. Make it big, audacious.
Next, you’re going to “brain spill.” In order to build a solution that will achieve the Product Goal, what do we need to do? Brain spill, brain spill, brain spill. Epic level, story level, task level, it’ll come in all formats – just brain spill it.
Because in the next step we’re going to group them. Small items combined are stories. Stories combined are epics. And you’ll start to see patterns, different patterns. The components to realize the value of this product; we need to have this part, and we need to have this part, and we need to have this part. You’ll start to see these things; group it, group it, group it.
And then prioritize it. Ordering. Among these different epics what are the important ones that you’re going to have to do. Within those epics, what are the important stories that you have to address. Within those stories, what are the important tasks you have to address. Break it down, break it down, break it down. Let the more important ones come up to the surface closer and closer to the top, and those are going to be the ones that because now it’s in smaller units, we’ll be ready for picking for Sprint Planning. This is how you build a Product Backlog. So that concludes the Scrum theory part and the Scrum practice part. From here it’s about doing Scrum so good luck about that.
In the meantime, for those going for a Scrum certification, if you do choose Scrum.org I have a few pointers for you so I hope this is going to be helpful. Note that I am not affiliated with Scrum.org and the following information is a share of my own personal knowledge from becoming Scrum certified. It’s my interpretation of the Scrum certification process so for accurate information go check the Scrum.org website yourself. I make no representation of accuracy of the information.
The most popular Scrum certification for Scrum.org is PSM, Professional Scrum Master. It has three levels and the first level is PSM 1. It costs you a US$150. You don’t have to take a $2,000-3,000 course to get PSM certified; you just have to take the certification exam. You studied with me today and pretty much you will be ready for that with some exceptions which I’ll explain. It’s a 60-minute test, 80 minute to MCQ test and you need to get 85% to pass. The link is here. There’s also an open practice assessment for that.
Similarly, if you are going to be the Product Owner for an upcoming Scrum let’s try becoming a PSPO, Professional Scrum Product Owner. Again, three levels, the first level is PSPO 1. It’s US$200 for the test. It’s electronic, you can immediately subscribe to that and you’ll be ready to do the test. 60 minutes, 80 questions, 85 percent passing score, same as PSM1. (Link to scrum.org PSPO 1 page | Link to Product Owner Open assessment)
There are three levels, PSM 1/2/3 and PSPO 1/2/3. You can see there’s a big difference between PSM 1 and PSM 2, similarly with PSPO 1 and PSPO 2. Indeed PSM 2 is pretty challenging, but as long as you have the basics of Scrum theory, Scrum rules covered, you should be able to pass PSM 1 and PSPO 1.
How do you prepare for PSM 1 and PSPO 1? Go to this link, for the left side is how you can prepare for the PSM 1 exam, and the right hand side is how you can prepare for the PSPO 1 exam. There’s a long list of reading material. The Scrum Guide is most important and today we really thoroughly have gone through that. Nonetheless there are a lot of additional things that you would want to look at the Scrum Guide from different perspectives so I do encourage you to look at the reading list and read as much as possible before taking the exam. And that goes same with PSPO 1. My count was I think there were about a little over a hundred documents each on the recommended reading list for each PSM and PSPO so it’s quite a lot of reading there. But it will definitely help you and especially if you’re going to do PSM 2 or PSPO 2, yes you do have to read all of that. My gut feeling is that PSM 1 and PSPO 1, you might not have to do all of the reading in order to pass.
What we covered today is quite in-depth and so the best way to see if you’re ready or not is to try the official mock test. Both the Scrum Open, this is for Professional Scrum Master, and the Product Owner Open, this is for PSPO preparation. Go through these, there are 30 questions each. Quite difficult, quite brain twisters. In the beginning, don’t be discouraged if you make a lot of mistakes because it’s about getting used to it. Once you read through the answers and check what you made mistakes and compare that against the Scrum Guide, it will make sense. And then keep on practicing the mock exam until you consistently get a hundred percent. Even if you’re going to take only PSM 1, I recommend you practice PSPO’s Product Owner Open as well because it will get you prepared. And then there are quite a lot of questions that come up from the Scrum Open and the Product Owner Open that shows up in the actual PSM 1 and PSPO 1 exam, so make sure you thoroughly do that.
One thing that we didn’t cover in today’s Scrum crash course is scaling Scrum. This one, Scrum.org’s choice of scaling Scrum is a framework called Nexus. It’s a lightweight framework and it doesn’t hurt to learn about that because there are a lot of commonalities with other scaled Agile frameworks, scaled Scrum frameworks, and there will be a few questions on scaled Scrum so you would have to prepare for that. So, go to these links, left one and right one, it’s a direct link to the long list of reading material for your exam preparation, particularly for the scaled Scrum and I think it was like five, six, seven articles that you can read and one is including the Nexus guide, so the Scrum Guide equivalent of Scrum.org’s preferred scaled Scrum framework Nexus. Go ahead and read through that and that will get you prepared for answering the scaled Scrum questions in the exam.
That concludes this crash course. It’s been a pleasure coaching you on this crash course, and I wish you very good luck on starting your Scrum. And if you’re going to get certified, I wish you very good luck on the certification as well. Contact me if you have any questions. Thank you very much. Goodbye.