GAQM CSM-001 Certified Scrum Master – Chapter 04 – Meetings in Scrum Part 3

41. Product Backlog Review Meetings

Since the prioritized product backlog is really the domain of the product owner, these particular meetings are generally driven by the product owner, but often facilitated by you. As Scrum Master, this requires engagement with the other relevant stakeholders and the Scrum team, and generally happens a few days before the end of the Sprint that we’re currently working. What we want to be able to do effectively set the table for the next Sprint.

Have things changed since the last time we groomed the product backlog? Have there been changes or other kinds of risks that have been identified? Do we need to reprioritize certain user stories based on changes in the customer’s priorities? And ultimately, how do we ensure that we are ready to do the next Sprint? That we have a product backlog that is and updated and reflects the current priorities of the business?

42. Facilitate Communications

So as you’ve seen, and we’ve worked our way through this course, the whole idea of Scrum is set up to facilitate lots of ongoing and informal communications among the team and also between the Scrum team and the various stakeholders, including the product owner. This is all predicated on one basic idea customer needs are going to change, requirements are going to be identified side that weren’t in the original list of requirements. And this has everything to do with the pace of change in business. Some of this may be based on internal business needs, some of this may be based on changes in customer expectations, competitive threats, economic conditions, changes in legal and regulatory requirements. Regardless, we need to be able to ensure that the product backlog reflects the current priorities in the business. So we’ve already learned a bunch of different techniques we can use with our customers to be able to prioritize user stories.

When we go about grooming the product backlog, we’re essentially asking for changes. Have the businesses needs changed? Do we need to reprioritize any of the existing user stories? Do we need to add new user stories? Are there specific requests for change? Are there new identified risks that we have to deal with? So again, the backlog itself belongs to and is specifically the responsibility of the product owner. But since we need to have a meeting and actually coordinate doing these updates, I’m going to encourage that the Scrum master really should be facilitating that session to leave the product owner free to collaborate more directly with their stakeholders.

43. Lesson: Sprint Review Meeting

In this next lesson, we’re going to start looking at what happens at the end of our sprint. At the end of the Sprint, we’re going to conduct two separate meetings. A Sprint review meeting to look at products with customers and a Sprint retrospective to look at processes with our Sprint teams. So in this particular lesson, let’s focus on the Sprint review with our customers.

44. Sprint Review Meeting

At the end of each Sprint, we want to be able to hand over deliverables that produce whole EndToEnd solutions for customers. When we define a set of user stories, we define a set of uses of a system, produce a set of results for the customer. And so, when we hand over a set of deliverables, we want those deliverables to be fully designed, tested, documented and potentially shippable if the customer decided the value was sufficient to do that. So, the Sprint review meeting provides us an opportunity for the Sprint team, the Scrum team in particular, to show off the solutions. Here are the user stories, here are the acceptance criteria associated with those stories. Here is the definition of done within our particular organization.

And we want to be able to do a full blown demonstration that the user stories are now in fact covered and supported to all of the appropriate customer stakeholders. This allows the product owner to specifically confirm that yes, in fact, these user stories are done and that the deliverables can be accepted and in some cases actually handed over through a release plan to the customer for use along the way. As we do a Sprint review, inevitably, stakeholders will request changes and those changes can absolutely be assessed and considered for subsequent Sprints and need to be then groomed into the product backlog so that we can prioritize where those should happen in terms of levels of effort and time, where there were issues associated with the Sprint. The Sprint Review meeting is a nice opportunity to describe what the issues were, how the Scrum team effectively addressed those, and then based on the deliverables handed over, the product owner can then review the updated prioritized product backlog.

Within any particular Sprint review meeting, the focus is very specifically on the product. What is the product that we’re handing over? Well completed user stories. Okay, so we had a set of user stories. We were intending to deliver this Sprint. What I really want to be showing is a live demonstration of those user stories. Not a lot of documentation about what we’re going to do or what we might have done, not stuff that’s been designed, but not actually tested and validated or documented. We’re trying to deliver done user stories here. If the user story is done, it goes off the Sprint backlog. At that point, it’s done, it’s been handed over. If it’s not done, if there’s any part of it that’s not done, then it has to go back into the backlog for consideration in the next Sprint.

Obviously, this can discourage a team if particular user stories find themselves going back again and again and again onto the to do list, essentially. And so it’s very important as the Scrum master to help your team identify appropriate acceptance criteria, ensure that the product owner is in fact counting as done. Any user story that is in fact meeting the user acceptance criteria and the definition of done. Now, if they want changes or new things, the next round, that’s fabulous. They go into the prioritized product backlog and they get prioritized based on where and when the customer would like that. Okay, where does that go relative to other things that are already in the backlog. But you need to be able to reward your team for being able to successfully deliver the user story according to the acceptance criteria.

45. Outputs of Sprint Review Meeting

So the key outputs that come out of the Sprint review are the accepted deliverables. Unfortunately, if we have any rejected deliverables that don’t meet the definition of done or have not met acceptance criteria, they go back into the product backlog for consideration at the next Sprint meeting to start the following week. Probably we need to update any information related to risks, any information that may impact the broader release plan, as well as any information about dependencies between our deliverables and any other deliverables that may be coming from other scrum teams. If we are tracking using a tool like Earned Value Analysis, this is also a good opportunity to update the appropriate Earned Value data.

46. Lesson: Retrospect Sprint Meeting

Where a Sprint review meeting is very much focused on the product and providing information to customers, stakeholders and specifically the product owner. About done user stories? This lesson focuses on a retrospect. When we do a retrospect for the Sprint, the focus moves internally to the team. How is the team doing in terms of working together as a team?

Are we being efficient? Are we being effective? Are we producing done user stories? Are we improving our velocity over time? And we want to be able to use Sprint retrospects to give the team a chance to do the team building and continual improvement activities that we want to see if we want to get improved performance from the team over time. Let’s talk about the role that you’re going to play as Scrum Master in facilitating a retrospect.

47. The Retrospect Sprint Meeting

It’s important as the Scrum Master to consider the frame of mind that your team is likely facing at the end of a sprint. They’re probably a little bit tired. They’ve just gone through the Sprint review where they’ve had their work on full display for their customers and for the product owner that may or may not have gone as well as they would have liked. And so at this point, we have an opportunity for some lessons learned. And so the idea of a sprint retrospect is to give the team literally safe space to identify ways to get better together. How can the team improve its own performance? As a Scrum Master, you’re going to host this retrospect at the end of each sprint, and I strongly encourage each one of you to be very creative about many different kinds of places you can hold a retrospect meeting.

I strongly encourage, wherever it is culturally possible in your organization, to do these offsite as far away from the madding crowd as possible, in places that are relaxing and conducive, to team building, to giving people safe space to talk about tough issues, and to be able to create opportunities for the team to get better together.

All of the Scrum team members are invited to attend and must attend this particular meeting. You are going to serve as the Facilitator. You may ask another member of the team to serve as your scribe, if that’s useful for you. You may or may not choose to invite your product owner based on the kinds of things that you feel like your team needs to wrestle with in that particular retrospect. You may not want the product owner there right away. On the other hand, it may be entirely appropriate to have the product owner there if some of the things that you want to discuss in the retrospect may have to do with collaboration with the product owner, for example, and how we’re grooming the product backlog in general.

The purpose of a retrospect is to look at three specific things. Things that are going fabulously, that we are doing and we need to keep doing. We’ll call those best practices. We want to be able to continue to do those things. We want to be able to look at things the team needs to begin doing. Maybe we’ve just started doing them for the first time. Are there particular process improvements we need to follow to improve the way the team collaborates and coordinates things? And then there may be very specific things that we accidentally or intentionally did that we shouldn’t do.

Again, inevitably, in any project, there are going to be lessons learned. Problems with communication and collaboration, problems with certain tooling, problems with certain workflow bottlenecks and other kinds of things. And when those occur, it’s extremely important to call them out and to be very specific about what we’re going to do differently to prevent those from happening in the future.

So taken together. This allows us to identify what we’re going to call our agreed actionable improvements, what specifically we’re going to go do differently next time to drive improved performance for the team. This may come with various specific action items, due dates and so forth. So unlike the Sprint review, where the focus is very much on the products themselves, on the actual deliverables, here the focus is very much more on our processes. How are we in fact doing the work together? Coordinating meetings, collaboration in the war room, testing and validation, various types of things? Are we siloing our work too much or are we working collaboratively to be able to support good practices across the life cycle of development?

48. Explorer -Shopper -Vacationer -Prisoner (ESVP)

There are a number of different techniques. As the Scrum Master, you can leverage and use in a retrospect to gauge where your team is and their level of comfort in being able to collaborate and support the retrospect with you. One of my personal favorites is called ESVP or Explorer. Shopper vacation or prisoner. I really just want to get a sense of where everybody is. I recognize, and you should too, that not everybody is all excited about the retrospect every sprint. In fact, there may be any of a thousand reasons why somebody wouldn’t be fully engaged. They’re tired. They have a personal issue. They have other kinds of things going on that affect their ability to engage. It doesn’t mean that they’re a bad person. Just we want to be honest about where everybody actually is. So we’re going to ask people to effectively self identify at the beginning of each one of the sprint retrospects. Now we’re going to do this anonymously because I don’t want to call some particular person out, but I want to know about where the team is. E for Explorer means that the person is wants to participate in learn everything they possibly can from the retrospect. They’re all in.

They’re really excited. A shopper. Yeah, I’m looking around. You guys can talk about a bunch of stuff. Maybe I’ll find something I like, okay, a vacationer is just taking a break. I’m tired. It’s the end of the sprint. It’s Friday afternoon. Maybe I’m going to be a tourist today. I’m just kind of hanging out. I’m here. I’m not really unhappy about being here, but I’m not feeling more productive about contributing. Prisoners actively want to be elsewhere and they’re there because I made them. Okay? And it’s important for us to understand when somebody feels like a prisoner, they feel like they don’t have a choice in doing certain kinds of things that reflects on their ability to participate in the team and to provide positive, constructive criticism of others.

So we want to be able to do this at the beginning of the retrospect. Strongly suggest that you do this anonymously because again, it’s not about who the prisoner is. If I have a prisoner or two on my team, I want to be able to share that with everybody. We have a couple of people here who are prisoners today. So it’s important to understand for everybody that there are a couple of people here who have other big things on their mind.

There are other things going on that they may need to be thinking about. And so they’re here because we ask them to be here, not because they would choose to be here. And please understand that that’s not how they are every day necessarily, but right now that’s where they are in their heads. What you’re going to find is that you’ll get very different feelings from different participants for different sprint retrospects. Not everybody hunky dory every day, and it doesn’t work like that. You can still have a very effective meeting, but you should have a full understanding of where your people really are to get a sense of what’s really consumable and achievable in that particular retrospect.

49. Speed Boat

Another of the key techniques you’re going to want to use in your retrospects is called speedboat. Speedboat is a pretty simple technique that allows you to identify potential opportunities or challenges to the team’s performance. And in the basic idea here, the team members roleplay like a team on a ship that’s trying to get to a particular destination. Allah the project vision. Okay, so you’re going to ask the team to, to identify, probably through some type of a brainstorming activity, any particular engines, things that if they had access to, would speed them up, things that would allow them to be more and higher productive.

After all, as the Scrum Master, you want to be able to remove obstacles to performance, but you can’t remove things you don’t know about. So you’re asking what do you need in order to be able to drive better and faster performance anchors? Are there specific things that are happening now that are slowing you down? We want to be able to identify these, we want to be able to prioritize these, and we want to be able to identify, where appropriate, certain types of mitigation options. So if we see certain kinds of boat anchors that are preventing us from being successful, what exactly would the team like us to do to try to address those? As the Scrum Master, really, our first and primary job is removing obstacles to team performance.

So this is a very specific technique and a very specific set of action items that will largely fall on you. You want to ensure that you have clarity about where your team wants you to aim, your efforts to be able to ensure that you are helping them be as productive and successful as possible. Speedboat in general is timebox to just a few minutes to keep everybody focused. My general rules of thumb is when I do brainstorms, I never go more than a couple of minutes because after about two minutes or so, you have almost everything that people want to say.

So if you brainstorm the engines and brainstorm the anchors, have them do a prioritization act, maybe using a hundred point method or something like that, and then help you identify certain mitigation options for the anchors. You can be done with this entire activity in 15 or 20 minutes, but it’s going to enable you, as the Scrum Master to be specifically focused on the things that are going to drive the most value for your team.

50. Metrics & Measurement Review

When you are planning a sprint retrospect, one of the things you’d want to do as the Scrum Master is think about what particular KPIs metrics and measures you want to share with your team. Now, one thing that people struggle with very much is this desperate need to provide lots and lots of metrics. And in general, most people aren’t going to respond to too many KPIs.

You want to pick and choose the two or three that are the most Germane or most appropriate for that particular time. Now, there’s many things you could focus on team velocity and velocity improvements done. Success rate, effectiveness of their estimation activities, feedback ratings on the deliverables from the stakeholder team, morale ratings if I run certain kinds of self assessments, any 360 degree peer feedback if we need to deal with a performance issue associated with a particular team member, or overall progress to release relaunch.

It’s amazing how people respond to thermometer type metrics that show how far along we are toward the overall launch or the successful delivery of the minimum required marketable features to get a solution into production for customers.

So, having now shown you a slide with seven bullets on it, don’t do all seven. Every sprint retrospect, please choose two or three that are meaningful for your customers and your people at this particular point in time. And for the retrospect, show the Scrum team the ones that you want them to focus on, if you want them to look at particular metrics or be aware of certain kinds of things. This is an opportunity for community, for you to show how certain things happen. That doesn’t mean we can’t share the other data in other ways, but let’s focus the energy on information that is valuable to that team in that particular retrospect.

51. Outputs from Retrospect Sprint Meeting

The key outputs from the Retrospect Sprint include the actionable improvements and then associated action items and due dates, the log associated with the Retrospect Sprint activities and what we did any documented lessons learned or recommendations for the Scrum guidance body. And you’ll notice that we also use this as an opportunity to find nonfunctional requirements as we’ve worked on our way through and produced a set of deliverables.

This will raise questions and concerns for solutions about non functional requirements performance requirement issues, capacity requirement issues availability and redundancy requirement issues, security continuity. And so when those things come out naturally as a result of doing a particular Sprint, we want to capture those non functional requirements, make sure that they are addressed as part of the overall prioritized product backlog for future Sprints.

52. Lesson: Release Planning Meeting

The next of the meetings we’re going to talk about is release planning. Now, release planning takes place at multiple stages during a particular project, certainly at the beginning, when we’re starting to look at overall requirements for marketing features and how much we’re going to need in terms of a solution to meet at least the initial thresholds of value that we can deliver out to the customer over time. As we continue to work through multiple sprints, we need to be able to effectively collaborate and coordinate, at which points we need to ship deliverables to customers and facilitate their handover to operations and delivery.

53. Conduct Release Planning Meeting

One of the things that differentiates agile models like Scrum from the traditional waterfall model is to be able to get early value into the customer’s hands. In other words, the customer does not have to wait for 100% of a solution to start getting meaningful benefits. So one of the things we want to be able to identify with the customer is at what point do we have enough of a solution that does enough things that the customer wants that it would make sense for that customer to start actually using the solution in production and taking advantage of the features and the value.

And so there’s a bias within agile models that as soon as possible we want to get high value functionality into customers hands and we see this in how the prioritized product backlog works. The intent here is to focus first and foremost on the things that are the most important and most valuable to the customer and preferably to get those out and in customer hands as immediately, as quickly as possible. So one of the things we want to be able to do is to work collaboratively with project sponsors and other customer stakeholders to be able to assess that we have shared expectations for delivery timelines between the Scrum team and the product owner and other stakeholders. At what point are we going to meet the necessary minimum feature requirements that the product really needs to be turned over for full operation and deployment into production?

A lot of this has to do with organizational release planning activities as well. At what point do we deploy new capabilities and features? In some organizations this is done on a continuous basis and might happen at the end of each sprint. Here’s a set of new capabilities and features and it gets rolled right in the same way an app you have on one of your tablets or smartphones may get updated to reflect the latest and greatest new features that have been identified by the design team in other organizational structures. We may want to phase this based on time that we do certain kinds of updates to solutions in the production space at certain iterations of time in ways that allow us to effectively manage risk and deliver the benefits of the business still, as quickly as it makes sense, given the organization’s priorities.

54. Outputs of Release Planning

So in conducting this meeting, the objective of the Scrum Master is again to facilitate the coordination between the product owner, the Scrum team and the customer stakeholders about how and when we want to be able to provide certain value back to the customer.

We also want to be very specific during our initial release plan to think about what the exact length of sprint we’re going to use for that project may be. So this starts at the very beginning of the project and may then evolve as we work our way through the project’s life cycle. In general, we want a fixed length of sprint somewhere generally between two and four weeks. Now, depending upon whether you’re looking at one or the other of the different Scrum methodology, best practice organizations, they may say that it caps out at 30 days, they may say it caps out at six weeks.

But generally speaking, most organizations run sprints of two to four weeks. We want to have a defined length of sprint before the project starts that we use for every sprint in the project. When we start thinking about the release plan, we want to think about that then in the context of how many sprints it might take in order for us to produce minimum functionality that’s going to be required in order for them to gain an appropriate level of benefit, which target customers will get. That whether we’re going to need to put together an appropriate pilot. And then given those do we need to make any updates to the product backlog to be able to ensure that we’re getting that minimum functionality in the customer’s hands as quickly as possible?

55. Piloting Plan

One of the things that we may end up doing along the way here is establishing the need for a pilot. We may have certain subsets of customers who we want to pilot our solution with to be able to get appropriate feedback on the propriety of that solution for broader distribution into the production space. Generally, when planning a pilot, you’re looking at the same key kinds of things the broad scope, open objectives of the pilot itself, which users you’re going to target with the pilot when that would be deployed out and then rolled back, ultimately at the end of the pilot.

What kinds of transition plans need to be put in place? Knowledge transfer, training, operational support, resources and so forth. What types of user preparation activities have to take place for a successful participation in the pilot? And then ultimately, how are we going to evaluate whether the pilot is successful or not? What key critical success factors are we going to measure to determine whether or not the pilot actually delivers the intended benefits for the customer?

56. Organizational Deployment Methods

A lot of the decisions about how exactly deliverables will be rolled into a production environment have less to do with the Scrum team themselves or for that matter, any of the aspects of what we’re doing within Scrum, but more about the organization’s preferences for release and deployment of solutions. Your organization will probably have formalized processes for release and deployment.

Management. And what we’re going to want to be able to do is first to establish at hat threshold we meet the appropriate minimum functionality needs, such that the solution should be vetted and delivered into production for actual use and then to have appropriate alignment and integration between our development teams and the organization’s formal release and deployment management processes so that we can effectively manage the Handover of Deliverables, facilitate our participation and validation in QA activities, assure compliance with security and other compliance requirements, and then formalize various types of user acceptance, testing and appropriate Handoffs with Customers stakeholders prior to deployment.

57. Communications Plan

As we’ve discussed a little bit throughout this course, scrum is fundamentally about improving communications and collaboration, not only within the Scrum teams and with the product owner and the Scrum Master, but with customers, stakeholders as well. And so part of what we want to be able to do in facilitating the successful performance of our Scrum teams as the Scrum Master, we want to have a collaboration with the product owner for how we’re going to facilitate appropriate communications with appropriate stakeholders.

Now, keep in mind what are the reason for how we structure Scrum is to facilitate those communications through the war room, through our information radiators, through frequent Sprint reviews and so forth. And so Scrum does not specifically say that we are going to create and execute a Scrum communications plan.

Now, that said, one of the things you want as a Scrum master is to figure out more or less who needs to be communicated with, at which point in time and how are we going to go do that? Who needs to be invited to the Sprint reviews? Who’s going to participate in user group planning meetings to be able to identify the prioritized product backlog? How do we facilitate coordination and communications among the Scrum teams if I have remote members? And so part of what we want to be able to do as a Scrum Master is to try to anticipate potential issues with communications and figure out how and with which vehicles we’re going to try to overcome those obstacles.

58. Lesson: Meetings in Scrum Summary

In this chapter we discussed a series of meetings that we’re going to facilitate as Scrum masters. And a big part of the objective, of course, is to enable the success of our teams to be able to facilitate communications and coordination with our Scrum teams, to be able to coordinate communication between the product owner and our Scrum teams and with other customer stakeholders as needed. So we went through a series series of meetings in many disciplines. We think about four key meetings within the Sprint themselves. The planning meeting, the Daily Scrum, the Sprint Review and the Sprint Retrospect. We’re certainly going to get involved in other meetings doing Elicitation and Requirements Project Visioning, as well as various user group meetings and workshops.

59. Meetings in Scrum Summary

The job of a Scrum master is to make sure that we are removing any obstacles to performance. When organizations use Scrum, they are providing a tremendous amount of responsibility to the individual teams to carry out and execute solutions to the business’s problems. That means that we as a facilitator need to ensure that they have a meaningful understanding of the business value of the desired business problems and the priority of those problems.

And that how our solution is going to effectively engage with and resolve those. We also want to be able to facilitate the successful execution of the Sprint activities and facilitate the use of Scrum practices and regular collaboration and self organization among the teams. The way that we do this is through a few formalized meetings and then largely about creating environmental structures that support that type of collaboration. So we might facilitate a project vision meeting to make sure that all of the project stakeholders have a broad expectation of what the project is for.

Why is this meaningful and valuable to the business? We may facilitate user group meetings to make sure that we’ve identified the epic user stories, changes and risks that may impact the project and that we were able to effectively support the product owner in prioritizing those according to business need and value. We’ll facilitate sprint planning meetings to enable the product owner to work with the Scrum team to identify user stories for a particular sprint and to be able to do appropriate task planning to figure out what tasks will most likely be needed and what the level of effort will be in order to produce the particular user stories in question.

As we work our way through the Sprint, we’ll help facilitate the daily standup where the team coordinates and collaborates with one another to explain basic questions like what did I complete yesterday? What am I completing today? Are there any roadblocks in my way? At the end of each Sprint will help support the facilitation of Sprint reviews and Sprint retrospect’s, to be able to review the results of our products and to be able to identify and drive improvements to our processes.

60. Chapter 04 Quiz

Now that you’ve had a chance to see the role that the scrum master plays in facilitating collaboration and communication among stakeholders through various meetings in scrum. Try your luck at these questions and see how you do.