GAQM CSM-001 Certified Scrum Master – Chapter 05 – Facilitating Projects in Scrum

1. Facilitating Projects in Scrum

In this chapter, we’re going to talk about some of the work that you’ll do as a Scrum Master in helping to facilitate the projects and the project timeline. In particular, we’re going to talk about effective use of artifacts in Scrum, talk a little bit about how you can support the Scrum team in actual creation of the Deliverables, and then talk about linking the work of your Scrum team, perhaps with other Scrum teams as part of larger scrum of Scrums for programs and projects. Let’s take a look at how these will work together.

2. Learning Objectives

The learning objectives associated with this chapter really begin with the effective use of artifacts in Scrum. We’ve talked already a lot about a number of different artifacts and tools you can use. In this chapter, we’re going to look a little bit about how to get the most effective use out of those. We’ll also talk a little bit of the role about the role of the Scrum master in broadly supporting the needs of the team during the sprints and how to scale Scrum practices to be able to support larger programs and portfolio management activities.

3. Terms to Know

The key terms to know in this particular chapter begin with the product backlog working. Deliverables agreements. Done. Criteria sprint backlogs scrum boards. Sprint burn down charts. Release burn down charts. Refactoring and scrum of scrums. It’s important, of course, not just to know what the definitions mean, but to know how to use these in the context of supporting a particular Scrum project.

4. Lesson: Scrum Artifacts

In this lesson, we’re going to take a more detailed look at some of the key scrum out effects how to support effective use of the product backlog how to support the team during the creation of Deliverables the use of the various aspects of the sprint backlog, as well as different types of burn down charts.

5. Prioritized Product Backlog

So in thinking about using a product backlog, in many ways the product backlog represents a realtime view of what the business’s preferences are. It provides an ordered list and also an emerging list of user needs, changes, risks and so forth that will be needed to effectively deliver on the project vision. So when you think about a product backlog, over time, it’ll end up including a number of different things functional requirements, various non functional requirements to support capacity planning, performance, security activities, continuity and the like, various risks that have been identified and need to be mitigated.

And part of what we want to be able to do in helping teams produce effective solutions is to use the product backlog to then focus on how, in fact, individual user stories are going to drive specific value to the customer. So the language you’re going to hear used regularly in the Scrum community is that we produce potentially shippable deliverables each sprint.

And the way that we do that is by doing vertical slices, essentially identifying particular uses of a service, and then producing whole working capabilities that allow an organization to actually carry out that value proposition all the way through end to end. Once you’ve, of course, initially established the backlog, we’re going to spend large amounts of time helping the product owner groom it over the life cycle of the project.

The product owner is responsible for the product backlog itself, but everybody on the team, including the Scrum Master, is encouraged to help contribute to it, especially around identifying non functional requirements and potential risks.

6. Product Backlog Items

So a couple things about using the product backlog. Eventually, of course, when we do each of our Sprint plans, we’re going to select items from the top of the product backlog to be able to consider for inclusion in the Sprint. And we want to be able to use the Sprint timeline to actually produce a whole working solution for that particular user story.

So in order for something to be included in the Sprint, the product backlog item has to be small enough to fit inside a Sprint window and it has to have fully defined acceptance criteria from the product owner so that we know what, in fact, it is we would use to measure whether or not that particular user story was done.

The other key thing that we need for the product backlog items is to be able to estimate the level of effort associated with actually producing that. It’s using various techniques that we’ve talked about planning poker, fist to five and the like, story points and so forth. We want to be able to assess how big a user story that might be, because as we start to get a sense from a team perspective of our velocity, we can start to think a little bit about how many user stories we can effectively deliver within each Sprint.

7. Ship Deliverables

The purpose of every particular Sprint is actually to produce not just a body of work, but specifically potentially shippable solutions. Now, at the end of each Sprint, we’re going to have a Sprint review and we’re going to actually demonstrate working solutions to customers and we want to be able to hand those over and potentially even to release those to the customer based on the release plan, the customers requirements and wishes. But that said, most Sprints don’t in fact, actually result in immediate release.

So, depending upon your organization’s release and deployment preferences, the product owner may work with the customer to come up with a broad release plan and what levels of particular shippable solutions we will need in order to meet whatever the minimum functional requirements are for the customer to produce a valuable solution for that.

That said, within Scrum, we want to ensure that we focus very much on helping the product owner and the customer stakeholders receive early value from solutions. So we want to help them understand and define at what point it makes sense for them to be able to introduce the new solutions into production for use, so they can start gaining benefit from the Project Team’s activities.

8. Outputs from Ship Deliverables

There are a number of important outputs when we ship deliverables to customers that we want to make sure are in place. One of them is to establish some type of a working deliverables agreement with them to make sure that the customer has an appropriate opportunity to sign off on acceptance of the deliverables.

And in many cases, if you’re working with third-party organizations, this may in fact trigger when we get to do revenue recognition for work that we’ve done on. Clearly we want to have a way to hand off the working deliverables for release and deployment planning by the organization. In addition to the releasing the content themselves, we want to be able to establish appropriate release notes for the particular deliverables that we’re handing over.

Remember, when we say we’re delivering fully, potentially shippable solutions, that means documented too. And so we need to make sure that all of those things were in place so that if the customer were to choose to release this to production, that they effectively were ready to go to do so.

9. Definition of Done

Now when we start thinking about establishing acceptance criteria for user stories and so forth, one of the things that you’re going to have to help the teams effectively understand is the notion of what done means. So one of the first things that has to happen within your organization, which will also often and generally happen through your Scrum guidance body, is the creation of a generic set of done criteria. Done criteria are designed to apply to all user stories.

They should be demonstrated and approved by the product owner and then each particular user story will then be augmented with specific acceptance criteria for that particular user story. In general, done criteria are fairly minimal, but we want to make sure that it reflects the orientation associated with delivering a whole working solution, what we often call the vertical slice orientation. So in order for something to be potentially shippable, it means that it has to be designed, has to be fully developed, has to be integrated, has to be tested, it has to be documented and usable, actually working.

And so one of the things you want to be able to help your teams do as the Scrum master is to help them successfully complete the particular user stories. They’re working in a particular time, in a particular Sprint, because any Sprint user story that is not done does not meet the definition of done at the end of the sprint, has to go back in the product backlog again, and then it probably gets dealt with some more in a subsequent sprint.

And so you can think about this in the context of a backlog that just keeps getting bigger and bigger and bigger because people come up with more ideas, but we’re not taking stuff out because we’re not getting things done. And this obviously has a terrible effect on team morale and also on customer morale because it seems like things aren’t ever getting quite finished and so we’re not really getting anywhere and the project tends to stall out.

So this of course leads to how carefully we have to help our teams make sure we have consumable user stories at the beginning of the Sprint that are estimated and sized in such a way that we can actually successfully facilitate them getting done during the Sprint timeline. Because we want them to successfully deliver the user stories and we want to make sure that we’re able to deliver them in a way that in fact meets the done criteria and the acceptance criteria for that story.

10. Sprint Backlog

So when we do the Sprint planning meeting, effectively what’s happening is the Scrum team and the product owner are negotiating what things on the product backlog are going to get handled in that particular Sprint. And so this is an opportunity for commitment. The product owner may present a particular user story for consideration and then the team has to look at it and understand something about what that’s going to mean, estimates of effort ultimately about tasks and what has to be carried out in order to deliver that particular user story. But we want to be able to create an appropriate level of commitment there so that the product owner has confidence that the team has committed to producing that particular user story or stories, and that the team understands what they’re committing to, that they have a good understanding of what that’s actually going to do.

Likewise, what we want to be able to do then is to use the sprint backlog to be able to provide a fairly detailed view for the team of the user stories, the various tasks that we think we’re going to have to carry out to produce the user stories and then to be able to use something like a scrum board to get organized, to be able to manage those tasks as we work our way through the sprint and to allow the team to manage itself as various tasks get worked on and as they work their way toward done. And they work the user stories toward done. So one of the things you’re going to want to encourage the team to do is to keep those types of information radiators really accurate so that everybody can see who’s working on which things and ultimately how we’re working through the tasks to produce the user stories in the timeline of the spread.

11. Scrumboard

So one of the ways that we’re going to help the team manage themselves within a scrum project is by giving them tools to allow them to communicate effectively together with one another. One of the favorite tools that we use on a regular basis is a simple scrum board. And if you look at a Scrum board, all it effectively is is a list of the user stories in the Sprint backlog and the tasks that have been identified by the team that need to get carried out in order to be able to deliver on that, along with some sense of the number of story points associated with that level of effort. And so what we want to be able to do is to be able to track and manage a couple of basic things. What activities need to get done?

Where are they in the various process? Are they just sitting as unassigned to do items? Have they been taken up by somebody and they’re currently in process or in verification? Are they successfully done and completed? And so effectively what we do in most of our organizations is the team manages this themselves. Once they’ve established the stories for the sprint and the various to do items, the principles of self organization suggest that they assign themselves the tasks, work through the tasks, assign themselves other types of activities as they go and work collaboratively liberatively together to be able to carry out all of the necessary activities to produce the user stories.

12. Sprint Burndown Chart

Another of the key artifacts you’re going to use to help support your team is what we call a Sprint burn down chart. Now, burn down charts in effort begin with the total amount of work to be done. And what we want to be able to show is, over time, how far along are we relative to the overall plan and how do we keep, as a team, our eyes on where we are relative to where we need to be so we can manage our levels of effort and make sure that the team effectively gets stuff done in time? So as the Scrum master, your job is really to be able to create broad awareness for your teams so that your teams have visibility into their burn down status, that you’re actively encouraging them to update the burn down. Chart based on their own activities and then to establish some kind of a regular update frequency user daily that allows you to be able to see where you are at any particular moment in time.

13. Sprint Burndown Chart – Graphic

So, if you look at this sample burndown chart, we start with the total number of work hours associated with a specific sprint. In this particular sample, maybe we have 600 hours total of work available to us, and maybe we actually have a sprint with effectively 19 working days associated with it. And so what we want to be able to show is, as the particular amount of time goes down in working days, where are we in terms of the work hours required to be able to produce the user stories in question? Now, what often happens in the beginning, as you see on this particular burndown chart, is that as we’re getting organised and beginning the sprint and just kind of trying to figure out what we have, you tend to have a little bit of a lull at the beginning and you tend to be a little bit behind where you would like to be. And then usually, what happens in the burndown is more or less what you see here on day five, when you start to see the team catch up and start to get ahead. And you can see some fits and starts as you work your way through different portions of the project. But you do want to make sure that the project timeline stays more or less on track. And so one of the things you can do to help your team is to track and manage the burndown every day based on the tasks that have been completed and the tasks that remain to be completed in order to meet the customer’s needs and deliver the user stories.

14. Release Burndown Chart

One of the other tools you can use to help motivate your team is to give them a broader view not only within the sprint, but how your burn down is effectively getting your organization ready to release different combinations of shippable solutions that we’ve produced in a set of different sprints. So what we want to be able to do is effectively show them, when in fact, it is that whole sets of our solutions that we’ve produced of them will be packaged up and released to production, to customers and to be able to show, relative to the broad product backlog, what percentage of that backlog has been successfully completed relative to a particular release that we’re going to do.

So the purpose of a release burn down is really to help the product owner manage product releases, but also to help the team see how the work that they’ve been producing in various sprints effectively moves the organization toward the broader sets of objectives they have for being able to realize all of the different value associated with the potentially shippable solutions we’re creating. So the product owner might use this empirical data and estimations to start thinking about when they can plan certain releases based on certain amounts of potentially shippable solutions that we’re putting together, and also allow us to establish an update frequency generally at the end of each sprint.

15. Release Burndown Chart – Graphic

So here’s a simple example of a release burn down chart. And in this particular case, I’m looking across a number of sprints. In this particular case, maybe I’m planning for a release after nine sprints worth of deliverables. And those nine sprints may represent 120 story points worth of effort, for example. And so what we’re looking at is, relative to the sprint plans, how exactly are we tracking for being able to release the necessary minimum functionality that’s required by the end of sprint number nine? And so you can see here that the team can track the number of story points that are remaining to be delivered relative to the objective of being able to release a minimum functional solution by the end of sprint number nine. While sprints allow us to maintain a very substantial focus on what we need to get done in the immediate term, at the same time, a release burned down chart keeps the team’s broader eyes on the prize of when we can release solution functionality to customers and they can start achieving value.

16. Lesson: Creating Deliverables

In this next lesson, we’re going to look at what happens during the sprint itself, how the team is working to create, deliverables and our role in helping to identify and remove impediments to the team’s performance as they work their way through.

17. Creating the Deliverables

So as the team begins executing work within a particular sprint, the main activity of course is actually producing the deliverables, being able to build solutions that will effectively support the user stories in question. Along the way we have our various information radiators that we can use to track and manage ourselves updating scrum boards. And in particular, one of the things we want to do is Scrum Master is to be able to identify potential impediments to the team’s progress.

Now again, impediments can be almost anything that impacts the ability of the team to perform. This can be specific technical issues, having access to the right tooling, having access to the right licenses, external dependencies that may impact the team’s performance. To be able to carry out work that they need to do can be something as simple as providing appropriate lighting for the workspace or making sure that they have access to the information and the people that they need to be able to get questions asked and answered.

So one of the things we want to be able to do with the team every single day is to be able to build and update any impediments that may occur. So as part of running the Daily Stand Up, for example, one of the three questions we’re going to ask is are there any impediments to the person being able to carry out their work if they identify impediments? Really the job of us as servant leaders is to help see what we can do to help remove those impediments in question. And so I think about the Daily Standup as continually building an action item log for the Scrum Master to carry out their work successfully.

18. Building Deliverables in Scrum

So one of the things that we want to be able to do is helping and support our teams is to make sure that they’re following good scrum and agile practices. That means reminding them on an almost consistent and continuous basis about some of the key aspects of scrum that play out as we’re going and building solutions. That means that the purpose of this particular sprint, for example, is to produce wholeworking potential shippable solutions. That means cross functional work that needs to happen. That means that what has to actually occur involves a substantial level of collaboration among the team members. Requirements, listation design, development, testing, documentation, demonstration at the sprint review and so forth.

One thing that you want to also consider as you’re working your way through here is to encourage your teams not to accumulate technical debt. So as they’re developing solutions, we want them to be able to do that in a way that’s efficient and that actually produces agile and flexible code for the future as well. So one of the methodologies that many organizations use to do this is to integrate what we call test driven development. In test driven development effectively, what we do is write the test first for a particular user story in question, prove that the existing solution as it is, doesn’t already do that.

So prove that the test currently fails because it doesn’t have that capability, and then write the code that’s required in order to effectively make that particular user story pass. Once you’ve done that, the last step, as you’ll see, is refactoring the code. How do we make the code more efficient, more effective, less redundant to be able to make the code clean and effective to use? Now again, the real benefits here occur downstream. We want to be able to create code that we can readily change. We want to be able to create code that will perform effectively and we want to be able to do this in a way that’s sustainable, that allows us to keep going. So a fundamental part of every sprint is not just creating capability, but creating capability that’s then refactored to work efficiently and well.

19. Refactoring

So in case you’re not specifically familiar with the idea of refactoring and development, part of what we want to be able to do is not just to have code that does whatever it says, but to have that code be of high quality. That means it’s maintainable, that means it’s relatively navigable, people can figure out what it is and we want to be able to do that in a way that makes the code it as simple and concise as possible. So the basic idea of refactoring is we want to be able to change the design of the code, presumably to make it more efficient, while not changing the particular behavior of the code, it still does all the things it was supposed to do.

So when we refactor code, we eliminate repetition. We take big methods and functions and break them into smaller, more easily reusable routines. We clearly define various variables and method names so that we know what we’re calling and looking for, for future needs as required. And then there’s a very heavy focus here on making the code simple, easy to understand and especially easy to modify because eventually, of course, we’re going to make changes, right? So you’re effectively setting the table for the rest of time as you refactor your code.

It’s like cleaning up your room in the morning. You really want to make sure that things are nice and neat and ready to go because you know you’re going to come back to this again and you know that you’re going to need to do different things later. And then you want to create an appropriate baseline to work from. So one of the ways organizations do this is by making good use of design patterns and other kinds of things to be able to simplify the structures around their code. We want to be able to set the code up as if we’re going to have to come back and figure out what it is and make changes tomorrow readily and easily.

Whether it’s me or somebody else who’s going to come in and look at the code, we want to make sure that it’s clean and concise. And this happens every single time we develop code. So in a test driven development type situation, for example, I’m going to write just an code to make the test pass be able effectively to demonstrate that the new code can in fact now deliver the new functionality. And then I’m going to spend the lion’s share the rest of the time making that efficient and making sure that that’s appropriately integrated now back into the code base so that it’s not sitting out as some other feature. It’s fundamentally part of what we do.

20. Lesson: Convening a Scrum of Scrums

In this next lesson, we’re going to talk more broadly about what happens with larger scale programs and portfolios of services. Scrum actually scales quite nicely to be able to support larger programs. But in order to be able to do that successfully, we’re going to have to think about architecturally,

how we’re going to convene and create communications between scrums of scrums to take my various Scrum teams and to be able to roll them up into larger sets of Scrum and scrums of Scrum teams that are working together in a larger scale program. Let’s take a look at this now.

21. Projects, Programs, and Portfolios

So many organizations, of course, have different portfolios of products and services that they offer to their customers and may then in turn use different programs to establish how they’ll build new capabilities across a number of different project areas. So when we use Scrum to manage our project activities, what we want to be able to do is effectively tie out and integrate the work of a potential particular Scrum team with other Scrum teams who may be working on different solutions as part of a larger program.

The way this is generally done is through very specific integration points. What we’ll call a scrum of scrums that align the work of broad based chief product owners who may be responsible for a whole portfolio of services to program product owners who may be responsible for their particular program down to the product owner for our particular set of activities that we’re carrying out in our Scrum team. Likewise, there may be the role of a chief Scrum Master who oversees all of the Scrum Facilitation activities across the portfolio of services, program Scrum masters who do the same for the programs, and then us as the Scrum Master, potentially for a particular Scrum team working on particular projects within the larger program.

So as we start thinking through how this connective tissue is going to take place, it really becomes about facilitating communications and managing dependencies. And so as we get into the Scrum of Scrums, we’re going to really need to do the same kinds of things that we do during a daily stand up. How do we make sure that we have effective communication about who who’s got what and how that may impact team performance?

22. Scrum of Scrums

So a Scrum of Scrums is a particular meeting that we want to have across the different Scrum teams. These meetings are relatively short but they are not explicitly timeboxed because in many cases this is the key opportunity for us to do appropriate and in many cases very detailed information sharing about particular dependencies across certain teams. We need to have one representative for from each of the Scrum teams. Oftentimes it will be you. You may at certain points feel it’s beneficial to send a particular member of the Scrum team to the Scrum of Scrums.

Especially if we’re dealing with a particular dependency either where we’re waiting on something for some other team or some other team is waiting on things from us so that they can ask and answer the questions that they will need. Generally speaking will hold a Scrum of Scrums at a set of predetermined intervals or as needed depending upon what’s going on within the larger program or portfolio. And so we want to be able to do this in the same way we do other communications activities. To be able to identify and manage risks, identify issues and in particular to deal with any dependency issues related to the work of other teams.

23. Four Questions per Team

So you’ll notice in the scrum of scrums that we actually use a very similar approach to how we conduct a daily standup together as part of our regular scrum team. Unlike this regular scrum, instead of three questions we’re going to ask for here, what has the team been working on since the previous meeting? What’s our team doing until the next meeting? What were other teams counting on our team to finish that might remain undone, that may create independencies for them? And what is our team specifically planning on doing that may affect other teams? And so we want to think through based on the sets of activities within a larger scale program where the external dependencies may be on particular deliverables or inputs from other teams.

And so we want to be able to ensure that all of those are better understood in the broad scale and those dependencies are taken into account. For example, when we do sprint planning, so that we don’t have a situation where teams are unable to complete the user stories and questions because of external dependencies that are going to miss the timeline, because these tend to scale to much larger groups of people working across different aspects of an organization. In many cases, a scrum of scrums can’t be colocated, in which case you want to be able, wherever possible, to leverage video conferencing to be able to people could actually see one another and actually communicate more collaboratively about what’s actually happening and have the kind of thorough discussions that we would typically have in a daily stand up.

24. Outputs from Scrum of Scrums

So the purposes behind doing scrums of scrums, of course, begin with collaboration and communications. We want to be able to work together with teams to identify dependencies, to be able to resolve any particular impediments to the performance of our particular team and to be able to ensure that the teams are coordinating together to support the larger program or portfolio management objectives.

25. Manage Distributed Teams

Sometimes as the Scrum Master we’re going to be put in situations where we have to work with and manage distributed teams. Now, as a practical matter, of course we don’t really manage the teams, they manage themselves. But as the Scrum Master we have to make sure that they can effectively collaborate and communicate even in situations where we can’t in fact have the team fully colocated.

So this means spending a tremendous amount of energy thinking about how to create safe and open communications, especially across the different noncolocated teams. This means use of video conferencing tools, electronic versions of collaboration tools and information radiators like Scrum boards and burn down charts and effectively putting yourself in the position of the person who is the most impacted in terms of communications and visibility.

If you were in that seat, how exactly is it that we could create a situation to allow them to be full participants in and collaborators on the team? We want to empower their ability to be successful being part of the team and that means really thinking all the way through exactly how it is that we enable them to be full and equal participants in what happens.

26. Working with Distributed Scrum Teams

Now this can take a lot of different forms and depending upon which kind of colocation issues you have, you may have to do some very specific kinds of things. If the product owner is in a different location, we want to be able to ensure, for example, that product grooming properly integrates the inputs of the scrum team. If the team is split among different locations, it’s going to be very critical to think through tools like collaboration tools that allow for pair programming, potentially with two people who are not in the same space, to be able to think about things like how collaboration and information radiators are made available in an effective and perhaps real time way across different portions of the team.

Even though some of the members are not colocated with others to be able to think about how specific practical issues of continuous integration and testing will occur with certain members of the team are not specifically located in that area. And then to think about how this is going to happen as we scale teams up over time, especially in the broader sense of scrums of scrums.

So if I have distributed teams that impacts the ability of the teams to coordinate and collaborate together, that impacts the ability of ours to maintain and keep our artifacts together and to be able to conduct our meetings in a clear and open way, it doesn’t mean we can’t do those things. It means that it’s going to create impacts.

And so we, as the scrum master in particular, need to deal with those as impediments. What exactly can we do to actually make a lot of those impediments go away or at the very least mitigate the impact that they have? And there in many cases this is about tools providing them appropriate access to things like video conferencing tools to provide them appropriate access to things like information radiators that are visible and electronically available to them in the same way as they were sitting in the room.

27. Lesson: Facilitating Projects in Scrum Summary

In this chapter, we talked about some of the practical aspects of being a Scrum master how to effectively use artifacts, how to support your team as they’re creating deliverables during sprints, and how to facilitate coordination and communication in larger programs and portfolios when we need to be able to participate in larger scrums of scrums.

28. Facilitating Projects in Scrum Summary

The purpose, of course, of any artifact within a project is to help coordinate and communicate among the various project stakeholders. And so, in keeping with the broader context of transparency and empiricism within scrum, we want to be able to ensure that people at all times have visibility into the tasks that need to be done, into the user stories.

We’ve committed into the self assignments of various tasks as people are carrying out their work and to be able to show broader burn down activity. How we’re doing getting through the work within a sprint, how we’re doing getting through the work required to produce a whole release of solution value to the customer and so forth. One of the things that happens when we create various deliverables with customers is that the Scrum master then really becomes responsible for helping to identify and remove various impediments to the team’s performance. We identify impediments on an ongoing basis, especially during the daily scrum or daily stand up.

And then what we want to be able to do as a Scrum master is think through how exactly it is that we can mitigate some of those impacts. Again, this can be almost anything from very esoteric issues like having access to the right licenses or the right equipment, to issues of lighting and facilitation and communications.

Lastly, if we’re working on a larger program or portfolio of services, we have to be able to put together appropriate alignment between what our team is working on and what other teams are working on to be able to identify potential external dependencies that may impact our team and to be able to identify where the things that our team is working on will impact others so that we can ensure appropriate communications, appropriate planning across the different teams and to be able to ensure that the program will successfully be able to meet its objectives.

29. Chapter 05 Quiz

Now that you’ve had a chance to look at some of the specific activities Scrum Masters engage in relative to supporting their teams, try your luck at the quiz and see how you do.

30. Course Closure

I hope you’ve enjoyed this Scrum Master certification program. In this course, we really tried to help you focus on the key things that you need to remember, not only to be able to focus on the Scrum aspects in the various meetings, but to really support your teams in their success. As the Scrum Master, we’re not a project manager.

Our job is to actually serve our teams and ensure that the teams have the resources and capabilities they need to be able to produce user stories and value for your customers. We talked about this in the context of key aspects like change and risk and quality. We talked about this in the context of how we use the meetings to facilitate collaboration and communications.

And we talked about it in the context of how Scrum supports visibility into what’s going on through some of our particular deliverables, some of our artifacts, and how we collaborate and communicate across different Scrum teams to support larger program and project management activities. I hope that you’ve had the opportunity to learn a lot in this course. We wish you good luck on your certification exam.