+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cert Prep: Scrum Master
Become a Software Project Manager
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
What a scrum master certification can do for you ?
Selecting transcript lines in this section will navigate to timestamp in the video
- We all want to be the best at what we do every day. We can say we're the best at what we do, but how do we prove it to those around us and those that might hire us for our next role? In the field of project leadership, certifications can play a vital role in proving that we know our stuff and can be entrusted with the most important business objectives. One of the top certifications in the field today is the Certified Scrum Master, or CSM. The CSM demonstrates your knowledge of and ability to work in the scrum framework. It's a great launching point to refine your skills as a scrum master, or to get started in a scrum master role. Hi, I'm Kelley O'Connell. I've been a CSM for more than 10 years, and I'm also an Agile coach. I've been leading teams and organizations through Agile transitions for 10 years. I'd love for you to join me on LinkedIn Learning as we prepare for the Certified Scrum Master exam..
What you should know ?
Selecting transcript lines in this section will navigate to timestamp in the video
- This course is for anyone who's preparing to take the Certified Scrum Master, or CSM, exam. You may have already learned that there are multiple organizations that offer this credential. You can take this certification through whichever organization you'd like. The content for all exams is generally the same, so this course will prepare you for any exam you choose. Preparation for the CSM includes the foundation of Agile values and principles. It also includes the fundamental values and practices of the Scrum framework. At this point, you should have a good understanding of Agile in Scrum. I recommend checking out the Agile at Work series and my course on Transitioning from Waterfall to Agile, as great starting points.
Agile overview ::
Selecting transcript lines in this section will navigate to timestamp in the video
- As you begin preparing for the Certified ScrumMaster, or CSM, exam, it's important to understand the context of the Scrum framework. By understanding this, you'll more easily grasp the concepts. Often, the terms Agile and Scrum are used interchangeably. The problem is, they're not really the same thing. In the early 1990s, small groups of software development professionals began developing advanced project methodologies. One of these methodologies, Scrum, was the earliest to evolve, however, there were other frameworks being developed at the same time, for example, extreme programming, XP for short, and test-driven development, or TDD, were appearing on the scene too. These individuals were interested in eliminating waste from their projects. In the process, they recognized they were competing with each other, but they understood they had the same goals in mind. So the founders of several methodologies, including Scrum, XP, and TDD, got together in February 2001 to discuss the similarities and differences among them. The result was the Agile Manifesto, which documented the overarching goals they all shared. They established the term Agile to represent all the lightweight frameworks that shared those goals. So, given the context, let's uncover why Scrum has become the most popular framework of the Agile family. Scrum is a very simple framework that's entirely focused on doing just enough preparation, just in time for development work to begin. The founders of Scrum understood that doing too much preparation too far in advance of the work resulted in poor design and a lot of rework, as teams learned more and had to change directions. Because of this insight, they proposed that the detail designs only happen close to when the work is slated to be done. They were interested in postponing all the decisions they could in favor of discovering details within the process of development itself. This maximized the efficiency of the developer. That, however, wasn't quite enough to produce the highest quality product they could. The other major shift in Scrum is the role of the business. They recognized it was impossible to deliver exactly what a customer wanted if the developers never got to speak to the customer. To combat this problem, Scrum insists that the customer become part of the team. Simply by making these two changes, Scrum teams immediately began producing better results more quickly than their traditional methodology peers. Since the Scrum framework is relatively simple to implement, it took off very quickly, and is now the leading methodology in the industry. That being the case, obtaining your CSM can be a critical stepping stone to furthering your career goals.
Scrum foundation ::
Selecting transcript lines in this section will navigate to timestamp in the video
- While scrum is the most popular of the agile methodologies, it's essential to understand the foundation from which all agile methodologies come. You might be wondering why it's so important. Well, in a nutshell, agile methodologies provide a highly flexible and adaptive framework. This means that once teams are formed and performing well, teams can adapt the framework to better suit their needs. However, if the team loses sight of these foundational philosophies, they may lose their way and revert back to bad habits that run to the effectiveness of agile. So, let's start by examining the Agile Manifesto itself. The Manifesto for Agile Software Development, Agile Manifesto for short, defines four principles to guide you. It says we're uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. That is, while there's value in the items on the right, we value the items on the left more. The most interesting aspect of the manifesto values are what they don't say. They don't say traditional project management methodologies are inherently bad. It only says there's a better way of doing things, a way that shifts our perspective from believing the process itself is valuable to believing the results of the process are more valuable. At its core, the better way is moving away from defined process management where passing through project stages and producing documents meant that value has been delivered. Those are the items on the right. Instead, we're shifting our focus to an empirical process. In an empirical process, the items on the left tell us more than a stack of documents or a date on a timeline can. The people and how they interact help us build working software. Working with our customers enables us to respond to their changes. Supporting the manifesto are the 12 Principles of Agile Software. These principles should be the filter behind everything you do as a scrum master, so let's look at them. What's interesting to note is that these principles can be aligned into three broad categories. They're all about, first, the customer and how teams work with them. Second, the team and how members are selected and how they work together. And third, the product and process. Specifically, how agile teams produce the best possible product. Together, the four manifesto values and the 12 supporting principles create the philosophy behind agile. Agile frameworks, including scrum, are highly flexible. Once you attain your CSM certification, you'll have the opportunity to adapt the framework to best suit your needs. When you do adapt, make sure to keep the philosophy as your guiding principle. If you do, you can't fail.


Scrum framework ::
Selecting transcript lines in this section will navigate to timestamp in the video
- One of the key things to understand about Scrum is that it's not a silver bullet that eliminates your problems. It doesn't do that, and as soon as you accept it, you can begin to deeply understand why Scrum is so valuable anyway. But if it's not a silver bullet, why has Scrum swept the project management world for so many years? Well, there are three simple reasons. First, Scrum is lightweight. You don't need a lot of processes or tools to use Scrum. You can use Scrum practices with any type of complex work. Second, Scrum is easy to understand. You could read the Scrum guide and get started without having any specific training. Would you be better at it after training? Of course you will, but it's not a requirement. And third, Scrum is hard to master. While that doesn't seem to make sense at first, bear with me as we work our way through it. Behind Scrum is the concept of empirical process control. This means that as we do our work, we're learning from our experiences. We make much better decisions when we base them on our experiences. The empirical basis of Scrum drives the behaviors that are the Scrum framework. Let's explore that idea a little more fully. There are three pillars supporting empirical processes: transparency, inspection, and adaptation. Transparency means that for empirical processes to work well, all aspects of the process we're using to do our work must be visible to the people doing it. These people need to understand and agree on what the work is, how the work will be completed, and what done means. Next, inspection means that the team frequently inspects the work they're doing and assesses whether they're moving closer to the goal. Closely related to inspection is adaptation. When teams recognize that their work isn't getting them closer to the goal or done, they adapt their practices and approach to change direction. To support the empirical process, there are four events prescribed in Scrum. These are the vehicles Scrum uses to drive the empirical process. They are sprint planning, daily scrum, sprint review, and sprint retrospective. These four events then form the essential core of your Scrum framework. Through them, teams gain the transparency they need to be successful and the opportunities they need to inspect and adapt. These pillars don't stand alone though. They're supported by the overall Scrum values of commitment, courage, focus, openness, and respect. When Scrum teams abide by these five values, trust is established. This trust then makes it safe to explore, experiment, learn, and solve tough problems. With only four prescribed events, you can see that Scrum is lightweight and easy to understand. As you consider how to instill the pillars and values into your Scrum team, you'll also see why it's hard to master. But the pillars and values leave room for creative problem solving, and that fuels its position as the most popular Agile framework. As a Certified ScrumMaster, you're entrusted with the duty to help your teams master Scrum. When you do, your value as a ScrumMaster is unbeatable.



The Scrum Team ::
Scrum master role ::
Selecting transcript lines in this section will navigate to timestamp in the video
- The most important thing to know about a scrum master is to recognize that the role is not the same as a project manager. The role isn't focused on defining a schedule, assigning tasks, and managing the work until it's done. The scrum master is only a manager, in that this person is managing the scrum process. As the process owner for scrum, this role provides a great balance between the development team and their key business stakeholder, the product owner. Let's look at some of the ways a scrum master does this. The scrum master helps the product owner stay within the process framework. They do this by first helping the product owner ensure the backlog is in good order and ready for the next sprint. Second, they also ensure the product owner doesn't demand too much from the team in any sprint. Next, the scrum master helps the development team perform at the highest level possible. That's a really broad statement, and obviously this takes many forms in practice. First, the scrum master protects the development team from outside distractions. That means being aware of what the development team members are working on and running interference if a team member's manager is asking them to do work outside of the product backlog. These conversations are not always easy, but it's the job of the scrum master to resolve these distractions. The second aspect of protecting the development team falls into the category of protecting them from itself. What I mean by this is that sometimes there will be pressure to overcommit to how much work the development team can do within a sprint. A key hallmark of the Agile Manifesto is that development teams strive to attain a sustainable pace. When a development team overcommits, they're outside the boundaries of agile and scrum. The scrum master will identify the signs of overcommitment and hold the development team accountable to rightsizing their sprint commitment. Third, the scrum master protects the development team from complacency. Sometimes when development teams have been together for awhile and they're feeling comfortable, they stop looking for ways to improve their activities and interactions. When this happens, the scrum master needs to help the development team identify further growth areas. Sometimes the development team can undercommit to sprints. This is another form of complacency. When the scrum master sees this behavior, it's their duty to push the development team to complete the most work they can with high quality. Finally, the scrum master owns the scrum framework itself. You might wonder what that means. Well, as the process owner, scrum masters can make changes to the scrum processes. They'll accept the development team's input on process changes, but ultimately the decisions on process lie with them. The scrum master will only make changes that remain in alignment with the scrum philosophy and values. For example, I once had a development team that only wanted to hold sprint reviews with our customers every other sprint. I considered their request and declined to make the change. Why? Well, the change was a simple one to make. That much time between demonstrating and getting feedback on our work would not have been in the best interest of the development team, the product owner, or the product. So while the scrum master has no direct authority over development team members, they do have autonomy and authority over the process. When you stay grounded in the scrum framework and lead your development teams to their highest performance, great things happen. You'll help them attain the best implementation of scrum.
Scrum master as servant leader ::
Selecting transcript lines in this section will navigate to timestamp in the video
- The term servant leader is the one most commonly associated with the role of the scrum master. It's important to understand what this means as you embark on your scrum journey. Let's start by breaking the term into its component parts. First, let's talk about leadership from the scrum perspective. The scrum master is the scrum process owner and leader. As the process owner, they're expected to understand, embrace, and act in ways that demonstrate scrum theory, practice, and values. This knowledge is translated into the actions that build the process. The scrum master instructs the development team, the product owner or PO, and the organization as a whole on scrum practices and values. As the scrum leader, they're responsible for helping everyone understand what actions do and do not benefit the development team. Now, let's look at the term servant in this context. When you're serving others, you're not focused on being the best or the brightest. When you're a servant, your focus is on enabling people and organizations to understand the process and adopt the values and practices related to scrum. The scrum master serves the development team, the PO, and the whole organization. This is a very broad scope of influence, so let's look at some examples of how the scrum master serves in each area. Let's start with the product owner. The scrum master serves the PO by helping the PO make sure the goals and objectives for the development team are clear, coaching the PO on best practices for product backlog management, guiding the PO on the empirical process and product planning, facilitating scrum events as requested or needed, and sharing their knowledge of agility and scrum. By serving the PO in these ways, the scrum master in ensuring the work that comes to the development team is in the best condition possible. This will maximize the value the development team can deliver. The scrum master also serves the development team but in different ways, like coaching the development team on self-organization and becoming cross-functional, helping the development team understand the scrum philosophy and values, guiding the development team on the scrum framework, facilitating the development team in problem-solving, and removing impediments. Finally, the development team exists within the context of the overall organization. The organization doesn't always know how best to support the scrum environment. Since that's the case, the scrum master also needs to serve the organization. They do this by coaching the organization on the right ways to adopt scrum, guiding organizational awareness and understanding of the empirical process, helping other scrum masters to be more effective, and assisting their development teams to achieve the high performance the organization needs. As you can see, being a servant leader is hard work. As a certified scrum master, you're leading in the ways of scrum and serving all those around you to live the scrum values.
Product owner ::
Selecting transcript lines in this section will navigate to timestamp in the video
- The Product Owner, or PO, is a critical role on every Scrum Team. The PO, just as the name implies, is the sole accountable party for the product the development team is building. It's important to know that the PO is just one person, not a committee or group of people. The PO is very strongly recommended to be a person from the business. This business representative needs to be experienced enough to answer development team questions. They also need to have sufficient influence in the organization to negotiate product backlog items or PBIs with their peers and leaders. And finally, they must have strong interpersonal skills across different levels of the organization to ensure support for the product and the development team. With these key skills, the PO is entrusted with making all the decisions related to the product. This is the individual the development team will turn to when it comes to questions of product vision and the features that are needed to attain that vision. While the PO has a responsibility to represent all the stakeholders of the product, the development team only takes direction from the person designated as the product owner. Further, the development team will only do work, but the PO includes in the backlog as a PBI. You can infer from this that the PO is responsible for maximizing the value the development team delivers. The Scrum process is dedicated to minimizing waste and maximizing value. Development teams minimize waste by only working on the right thing, they maximize value by working on the right thing at the right time, and completing the work with high quality. So how does that relate to the PO? Well, in keeping an ordered product backlog, the PO is communicating what is the right thing to do and when is the right time to do it? Since the product backlog is the communication vehicle for this critical information, only the PO can make changes to it. For organizations that are new to Scrum, this can be a difficult hurdle. The PO is entrusted with this responsibility for the product and the value to be delivered. As such, the PO makes final decisions on product-related topics. The organization then needs to accept and support the product owner's decisions. There are times when the person selected to be the PO can't dedicate the amount of time the development team needs. When that's the case, a proxy can be selected to act in their place. However, it's important to note that the named PO, not the proxy, has the ultimate responsibility and accountability for the product. Including a proxy for the PO can delay decisions for the development team and pose a risk to the work. In some cases, this can't be avoided, so the Scrum Master needs to understand how to help the proxy and the PO navigate the Scrum framework effectively. The PO is a critical role on the Scrum Team. As a certified Scrum Master, you'll need to work closely with your PO to help them maximize value.
Product owner responsibilities ::
Selecting transcript lines in this section will navigate to timestamp in the video
- As the sole party responsible for the product being built, the product owner, PO for short, has many responsibilities. The primary focus of the PO is the product backlog, backlog for short, and all the product backlog items, or PBIs, it contains. While the accountability for the backlog and its contents lie with the PO, the responsibility for it can be delegated to the development team. I've often seen cases where the PO will partner with or delegate to a business analyst to help build out the backlog. Also, there are PBIs that the PO may not understand, like technical work. In those cases, the PO will often delegate these PBIs to the technical resources on the development team. Even though this delegation happens and assistance is willingly given, the PO remains accountable for every PBI in the backlog. Here are some other responsibilities of the PO. Clearly expressing the PBI so the development team knows what to build and what done will look like. Ordering the PBIs to maximize the value being delivered by the development team. Making sure the backlog is visible and available to all team members and across the organization. Clarifying the requirements that are represented as PBIs, and providing status of the work and what's coming up next in the backlog. There's one other responsibility that the PO has, sometimes it's necessary to abnormally terminate a sprint. This is very rare, but it does happen sometimes. Usually this has to happen when the PBI being worked on is found to no longer have value. For example, if the development team is working on a way to print an identification card, and the PO just learned another team is building an electronic identification card, the PO may decide that the print version is no longer valuable and halt the sprint. Another example of why a sprint may be terminated is that the output from the current design doesn't meet expectations of quality or performance. For example, if the development team is building a mobile application to display member profile and the screen load is taking far longer than expected, the PO may choose to terminate the sprint because it might actually be faster to start over than to do the rework necessary to fix it. One thing the PO is not responsible for is managing the development team. POs are only responsible for managing the backlog, not the people. The PO responsibility list is long. As a Certified Scrum Master, you can help guide your PO to building a great product using scrum.
Development team ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Let's start by differentiating between the Scrum Team and the development team. The Scrum Team consists of the product owner, Scrum master, and the development team. The development team is the specific group of people tasked with creating a potentially shippable product increment at the end of the sprint. So, who's on this team to make that happen? Well, very simply, the development team is the group of people with all the skills needed to do the work that's defined in the product backlog. It seems simple enough until you start exploring some of the details. The development team consists of three to nine people. Fewer than three development team members has been proven to be ineffective. There just isn't enough interaction to generate substantial productivity gains. Another challenge with a team this small is that they may not have all the skills they need to create a potentially shippable product increment at the end of a sprint. On the flip side, more than nine people really adds complexity to collaboration and communication. This complexity results in greater risk, as more time is spent communicating than you otherwise need. This could potentially result in less productivity. Remember that the product owner and Scrum master are not included in the development team size, unless they're also building the product backlog items. The whole focus of the development team is to produce a potentially shippable product increment at the end of the sprint. The work in this increment must be done at the end of the sprint even if the PO decides not to ship it yet. If the PO chooses not to ship or release the increment, the importance of getting the item to done is that the development team is demonstrating progress and receiving feedback. When teams do this, the PO and stakeholders have an opportunity to adjust course if there are additional items to add to the product backlog. Development teams have a few essential qualities that lead to high performance. First, the teams are self-organizing. That means that neither the PO nor the Scrum master can tell them how to build the PBIs. The team determines how to generate a product increment from the product backlog items. Second, the teams are cross-functional. That means the team has all the skills necessary to complete the work in the product backlog. Third, development team members don't acknowledge roles or titles. That means that everyone has the same role, that of developer. Team members can have specialized skills, but they're all expected to do whatever needs to be done to complete the product increment. This is known as generalizing. As an example, I once had a team member with a background in business analysis. She was interested in helping the team by learning some database analyst skills too, so she also worked on those types of tasks. No one on the development team is assigned or assigns themself a PBI. The ownership for completion of all the PBIs is shared collectively by the team. Team members will sign up for tasks on a PBI, but the whole team has accountability for the entirety of the PBI. Scrum development teams are a bit different from traditional project teams. The sense of self-organization, collective ownership, and complete equality is a unique occurrence. As a certified Scrum master, you'll help your team attain this mindset. From there, you'll guide them into becoming a self-organizing, high-performing unit.
Shared resources ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Scrum practice strongly recommends that a development team will have all the skills on it that are needed to get the product done. However, sometimes it's not possible to have all the necessary skills dedicated to your team. So in this instance, Scrum allows the usage of shared resources. Perhaps you only need a specific skill for a short period of time. An example is the need for a security engineer for a customer website the team is building. You may only need this skillset early in the project as the development team is working through their security design. Another example is perhaps the development team will intermittently need a database analyst, or DBA, off and on throughout the project. In both of these cases, as the PO and development team identify and ad PBIs to the backlog to represent this work, you can begin letting those people know the timing of the team's need. Having these shared resources come in and out of the project can cause disruption to team dynamics, so the focus needs to be on minimizing that. The best ways to reduce disruption is to include those shared resources or temporary resources early on. It's important for them to understand the big picture of what the team is building. This will also provide them information on when they need to be closely involved. For example, perhaps there are design decisions the development team needs to make early on that will affect shared resource contributions further down the road. In this case, you'll need to make sure communication channels are established. In that way, you'll ensure they receive all the information they need throughout the project to ease their entry to the work. It's also important for those individuals to understand the product backlog and rough timing estimations of when they'll need to be actively involved. As you provide awareness to those temporary team members, you can also set expectations around their level of involvement. Let's say your project will run 10 sprints and the development team needs that DBA to help complete work in sprints three and five. Knowing this, you'd engage the DBA at the beginning of the project so they understand the big picture. Next, you'd set the expectation that they attend daily scrums during sprints one through five. But, they'd only contribute with a scrum update in the sprints when they're completing work with the team, so sprints three and five. Using these techniques, the shared resources become a part of the team when needed, sprints three and five. At the same time, they've become established before the need as subject matter experts. In this way, you can minimize the disruption to the development team and maximize the ability of the shared resource to contribute effectively. As a Scrum master, it's your responsibility to help the Scrum team become high performing. Using strategies like this will help you get them there.
Establishing norms ::
Selecting transcript lines in this section will navigate to timestamp in the video
- While not required by scrum, team norms, or working agreements, are a good thing to establish. When you take the time to lead your scrum team through a norming session, you're helping them move more quickly through the team growth stages of forming, storming, norming, and performing. In essence, you're helping them get to the performance stage faster. So what goes into team norms? Well, the goal is to help all the individuals express behaviors that will help them perform at the best of their abilities. As the scrum master, and owner of the scrum process, your tasked with helping the scrum team become high performing. Helping the team establish these norms early on helps you get them to high performance faster. So what are the topics generally covered by team norms? Let's examine some common categories. Norms should cover the way team members interact with each other. This category covers things like, all opinions, and ideas will be considered equally and thoughtfully. Team members will ask for help as soon as they know they need it. Team members will keep their commitments to each other. And team members will hold each other accountable to maintaining the team norms. Another area norms often cover is how the team will communicate. In this category, you often see expectations that everyone will speak respectfully to each other, and thank each other for their contributions. Meeting interaction is another common area for team norms. In this category, we see norms like, electronics will be used in meetings only with team consensus and agreement. Further, you can stipulate that meetings will start and end on time, and perhaps the team will prefer there be no meetings before 9:00 a.m. These are common areas on which teams set norms. Decision-making norms are also common among teams. The team may decide that they'll make decisions by consensus. When timely consensus can't be reached, majority will rule and all team members are expected to honor the decision. Finally, it's important to establish norms around conflict resolution. On teams, conflict is practically inevitable, so it's a good idea to establish a norm in this area right away. An example of this type of norm is that team members agree to resolve conflicts among the team members first, before escalating the issue outside the team. This is just a sampling of topics on which norms can be established. There are many more areas you can norm on. At the same time, don't establish so many norms that the team can't keep them straight. I suggest starting with a few norms, and adding more as the team identifies a need. Your team norms are living agreements. What I mean by that, is it's a good idea to revisit your norms every sprint or two. You can add and remove from the list as needed, based on team consensus. While team norms are not required in the scrum framework, it's a very good exercise to establish a few early on. It will help you lead your team to high performance faster.
Team spaces ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Generally, Agile methodologies, as a whole, prefer teams to be co-located. This is recommended because it simplifies communication and collaboration on teams. Further, when team members are seated near each other, they overhear each others' conversations. This is known as Osmotic communication, and can help team members learn from each other and share information in a timely manner. However, co-location by itself doesn't necessarily provide everything team members need to be successful. For example, I was once assigned a conference room to work in with four other people. Sounds like an ideal Agile team space, doesn't it? Well, it wasn't, my conference roommates were very technical, and their work required a lot of intense concentration. My job, however, required me to be on the phone all day with vendors. Needless to say, my roommates didn't like sharing space with me. So what does that tell us about Agile team spaces? Well, it taught me the lesson that co-location is great when you need to collaborate, but it's not so good when you need to focus and concentrate. In the end, I realized that teams need both spaces to share for collaborative work, and spaces to escape to for quiet, focused work. Giving team members both options and allowing them to choose which to use based on their work is ideal. This design idea is called caves and commons, and places quiet rooms close to common areas, allowing people the freedom to decide where they need to be at any given moment. Another common challenge teams face today is the issue of distribution. More and more teams have members scattered across the globe. Since this has become the new normal, it's increasingly important that your team space adapt to the challenge. The easiest way to adapt is to ensure your team members have an electronic space where they can collaborate and share information. Many teams are using an Agile Lifecycle Management tool, like Jira, or VersionOne for this. Some teams are using SharePoint sites or other document repositories. But how to replace that co-located, interpersonal interaction, well, thankfully, we live in a time where platforms for this are abundant. Tools like Slack, Skype, and even FaceTime can help your teams feel like they're co-located even when they're not. No matter what team space you set up for your team, it's important that critical information is available. Having things like your product vision, team norms, and burn charts in your team space will help your team stay focused on the goal. Envision the perfect space for your team. Now that you know what that looks like, go set that up for them.
Scrum Events ::
- Scrum event overview
- Sprint Planning
- Daily Scrum
- Backlog Refinement
- Sprint Review
- Sprint Retrospective
1. Scrum event overview ::
Scrum events overview
Selecting transcript lines in this section will navigate to timestamp in the video
- Ken Schwaber and Jeff Sutherland are considered to be the pioneers of the Scrum framework. Their work dates back to 1995. The result of their work is the Scrum Guide and it's freely available to all Scrum practitioners. In the Scrum Guide, there are four prescribed formal events. They are sprint planning, daily Scrum, sprint review, and sprint retrospective. In contrast, Scrum Alliance refers to these events as activities. They've also included a fifth activity and that's product backlog refinement. As you prepare for your CSM exam, it's important that you understand all five and we'll cover them all in detail. One thing that's common to both the Scrum Guide and the Scrum Alliance is that all events provide a formal opportunity to inspect and adapt something. They're designed to offer opportunities for transparency, inspection, and collaboration. Additionally, all events take place within the context of the sprint. The sprint is really the heart of Scrum. Every sprint, just like each event, is timeboxed to a recurring cadence of less than a month. You might be wondering why sprints should not last longer than a month. The simple answer is that if they do, you're not providing the team the chance to inspect and adapt either the product or their practices often enough. During the sprint, the development team is expected to produce a potentially shippable product increment. As soon as one sprint ends, the next one begins until the product backlog is completed or the PO decides no more work is necessary to increase the value delivered. Each one of these events resides within the sprint and has a specific goal in mind. Since Scrum is focused on minimizing waste, applying a timebox is an effort to ensure the events are fit for purpose and provide value to the team. The timebox for each event expands and contracts in relation to the length of the sprint. The only exception is the daily Scrum which is always 15 minutes. Two-week sprints are the most common. For every event, other than a daily Scrum, you can timebox each event shorter or longer depending on your sprint length. So, for a one-week sprint, sprint planning would be two hours. For a four-week sprint, it would be eight hours and so on. These events establish the working rhythm for the team. As the Scrum Master, you'll work with the Scrum team to make sure these events are happening each and every sprint. This is one of the keys you'll use to help them become high performing.
2. Sprint planning ::
Selecting transcript lines in this section will navigate to timestamp in the video
- If the sprint itself is the heart of Scrum, then sprint planning is the lifeblood of the sprint. I realize this is a bold statement, but consider this. In sprint planning, the product vision and backlog are transformed into an actionable plan for the delivery of a product increment. As a Scrum master, it's your job to ensure that this happens every sprint with the right people and within the correct time box. Further, you help facilitate the discussion and remove any impediments. There are defined goals and objectives for sprint planning. In the Exercise Files, I've created a sprint planning guide for you, I've used this one with my Scrum Teams and you're free to use it as well. Like any good meeting, you'll need to do some preparation in advance. So, what do you need to know going into sprint planning? Well, there are a few inputs to the sprint planning meeting. First, you'll need your ordered product backlog. This is the source for the product backlog items from which the development team will choose their work for the sprint. Second, you'll need to know what was completed in the last product increment. At the end of every sprint is a completed product increment, so knowing what you accomplished last sprint can influence what the team will do this sprint. Third, you'll need to understand the past performance of the development team. Usually known as velocity, this is a powerful gauge of what they'll accomplish this sprint. Finally, you'll need to know the development team's capacity for the sprint. Quite simply, this is so you'll know who's out of the office or has otherwise diminished capacity for work. This information will help you keep the team from over-committing in the sprint. So, now that you have all this great information, what happens next? Well, there are always two questions that need to be answered in sprint planning. What will we do that results in a product increment? And how will we do it? The product owner will present a list of candidate items to the development team. For their part, the development team decides which items should come into the sprint. This is restricted based on the previous performance and capacity information you've already gathered. Once the items are selected, the Scrum Team determines what the sprint goal is. The sprint goal is a summary of the work and value that will be delivered in the product increment. For example, if your team is working on a project to develop self-service functionality for your company's website, perhaps your sprint goal is to implement password change functionality. So, now you've answered the first question, what will we do? Next, the team will move into the second half of the meeting where they create their plan on, how will we get the work done? In this half of the meeting, the development team defines the tasks it takes to complete the product increment. Each task should take less than one day to complete. Overall, the outcomes of sprint planning are the sprint goal, the backlog items for the sprint, and the plan for completing the work. It's important to note that the sprint backlog items plus the plan for the sprint become what Scrum calls the sprint backlog. Now that you've taken your team successfully through sprint planning, they're ready to tackle their work and deliver a high-value product increment.
3. Daily scrum ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Coming out of sprint planning, the scrum team has full understanding or what the development team will do during the sprint and the plan for how they'll complete the work. This is the sprint backlog. In traditional project management, once a plan is established, the project manager follows up with the team to track progress on every task. As a scrum master, you won't be doing that. In fact, you don't even have to attend. However, your tasked with ensuring the event occurs each day and doesn't exceed the 15-minute time box. According to the Scrum Guide, the guidelines for the daily scrum are that it's attended and facilitated by development team members. The scrum master doesn't attend the daily scrum, only ensures that it's taking place each day, and remains shorter than 15 minutes. And the PO does not participate in the daily scrum. However, according to the Scrum Alliance, the guidelines are a bit different. They are that the whole scrum team attends the daily scrum, any member of the scrum team can provide an update on scrum, and any interested party can attend the daily scrum, so long as they don't contribute. As you prepare for your CSM exam, it's important that you understand both perspectives on the daily scrum. In my experience, the Scrum Alliance format is more commonly used. The Daily Scrum Guide that I have included in the exercise file, takes both into account. Where both organizations agree is in the conduct of the daily scrum. First, the scrum master does not conduct this event. They ensure it takes place and is effective. By effective, I mean that it remains in the time box and conveys the necessary information. After all, it's a very straightforward event, and is entirely focused on inspecting and adapting within the sprint. Each team member answers these three questions. What did I do yesterday to help meet the sprint goal? What will I do today to help meet the sprint goal? And what impediments do I have that are blocking me or the development team from meeting the sprint goal? The result of this information is awareness about how the team is progressing toward the goal and any obstacles that they need to tackle. By obtaining clarity each day on these items, the team is giving themselves an opportunity to inspect how they're doing and adapt their approach if the need arises. They don't have to wait until the end of the sprint to know how things are going. After the daily scrum, members of the development team can meet to discuss the details of the daily scrum and adapt course if needed. This is also an opportunity to offer assistance to their teammates if needed. The daily scrum is the most important and powerful inspect-and-adapt opportunity in the sprint. As a scrum master, helping your team master this critical event will ensure they move forward faster toward their sprint goal.
Comments
Post a Comment