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

1. Meetings in Scrum

In this chapter, we’re going to go into some detail about the various meetings that take place in Scrum, and specifically your responsibilities as a Scrum master to help facilitate those meetings and to support the needs of the Scrum team.

We’ll talk a little bit about the Project Vision meetings, user group meetings to identify and document requirements, the Sprint Planning meeting, the daily Scrum Sprint reviews, and then Retrospects. Let’s take a look at each one of these.

2. Learning Objectives

In this particular chapter, you’re going to specifically learn how to facilitate the different meetings within Scrum project visions, user group sprint planning, daily standups sprint reviews and retrospect’s. In thinking about facilitation, broadly speaking, it’s important to remember that your job is not to direct the meeting, but to enable the teams to find their way and to facilitate how the stakeholders are able to produce the results from the meeting.

3. Terms to Know

There are a number of key terms to know associated with this chapter, including the names of the meetings themselves, project Vision, User Group meetings, Sprint Planning Meetings, the Daily Standup, the Sprint Review and Retrospective, as well as various techniques that we’re going to use along the way. Jazz sessions and squad analyses and gap analyses epics and personas and user stories. Planning poker and fist of five and scrum boards and sprint burn down charts, even ESVP speedboat and velocity.

4. Lesson: Project Vision Meeting

In this first lesson, we’re going to talk about the role of the scrum master in facilitating a successful project vision meeting.

5. Create The Project Vision

Before you can begin a successful project, you need to have clarity about what the project is intended to do. Now, we may have a defined business case that may serve as the trigger to kick off the project, but in this case, we need to have more detail about what the Win theme is. What are the organizational objectives? How does this tie into broader organizational mission and vision?

If there were previous proof of concepts, how is this supposed to help realize certain benefits for the organization? How does this help us respond potentially to certain market studies from customers or competitors? Now, we may have many tools at our disposal to do this, but ultimately we want to be able to help the customer find the desired set of outcomes they want.

What exactly will happen when certain types of products or services are provided to them? And how does this support the needs of the various stakeholders? As is true with all facilitation, really the objective here, as the scrum master, is to enable the customers and other stakeholders to find their own vision.

How exactly is it that this solution solves something? What’s the business problem it’s intended to solve? What’s the opportunity that it allows us to deliver against? And eventually, in order to have a coherent team working in a coherent project, we have to have a common shared vision. What is the project intended to do? What are the deliverables going to be used to do? And how exactly does this help the organization achieve the vision intended?

6. Project Vision Meeting

So in order to help the team produce an appropriate project vision, we’re going to establish and organize a project vision meeting. Now, keep in mind, we want to engage with all of the appropriate stakeholders, both on the customer and user side, as well as members of the potential scrum team, to identify the broad context by which this particular solution solves a business problem. What is the use of this particular solution? How and who is going to use it? What are in fact the business’s requirements and metrics for success? How would we know if we were successfully able to deliver a solution to this problem?

And how do we identify and document other appropriate stakeholder expectations for what the project should produce? So it’s very important in facilitating scrum activities to create the expectation with customers and other stakeholders that this is an ongoing conversation, that we are going to continually be coming back to them with solutions based on certain user stories they’ve identified that they in turn may request changes.

They may request to reprioritize certain features that they would like. And we want to be able to explain that the success of the team is a collaborative success. It’s through effective and ongoing communications between the goals and objectives of the project and the stakeholders who are going to be working to provision and deliver that that’s going to make for a successful endeavor. So this begins with establishing a project vision, a north start, but it’s going to continue throughout the project’s life cycle, especially when we start looking at specific epics and user stories.

7. JAD Sessions

Now, one of the things that you’re going to be asked to do as a Scrum master is to facilitate various types of requirements workshops. Now, even though we talk a lot about Epics and user stories in Scrum, there’s nothing to prevent you from using any other type of modeling techniques or elicitation techniques you may wish in order to gather requirements from customers. This may include interviews, questionnaires, various types of workshopping activities, modeling of use cases and process models and so forth. Regardless, what we want to be able to do is to get deep consensus on the scope of what it is we’re trying to do, the broad objectives and specifications of a successful, delivered solution, and to be able to leverage some of our agile techniques to be able to support the time boxing of meetings and to be able to prioritize and focus the team’s efforts on which things we’re doing, at which points in time.

So, jazz sessions and other types of requirements workshops are important in helping us create the collaborative environment between business stakeholders and the Scrum team stakeholders. And this is something we want to foster on an ongoing basis as a Scrum master in order for us to be successful. The fundamental agile principle here is one of collaboration and individuals interacting together. That requirements are going to be discovered and continue to evolve throughout the life cycle of both the project and the broader product or service that we’re going to produce. And so by creating the collaboration environment and creating safe space for people to share feedback feedback, we’re going to create better solutions for customers in the long run and enable our team to serve our customers well.

8. SWOT Analysis

Another of the techniques we can facilitate with our customers to help define their project vision is to allow them to establish an appropriate end state. In other words, as a result of having some particular solution to a particular business problem, what does that in fact get the organization to do? How does that define what we would really like to have happen in the future? And then based on that, we can do a SWAT analysis to start looking at the relative things that might both create opportunities for us and potentially create risks for us.

So strengths and weaknesses are internal to an organization strengths, perhaps things we already do very well that we can leverage and do even better. Weaknesses, perhaps things that we’re going to need to shore up or watch out for, that could get in the way of project success. And as the Scrum master, a big part of your job may be to identify and try to remove some of those impediments. Likewise, opportunities and threats are external opportunities create positive external opportunities for delivery of additional value. Those might justify certain actions. Likewise, certain types of threats or risks in the environment need to be identified and appropriately MIT negated to prevent the value from being threatened.

9. Gap Analysis

In many organizations. Rather than building entirely new solutions, we’re going to be adapting and building changes to be able to produce new levels of capability and outcomes for the business. In most instances, when we’re doing continual improvement type projects, one of the core techniques that we’ll use is a simple gap analysis. In short, we want to be able to define existing performance and process activities.

We want to be able to identify future desired performance, and then we want to establish a gap. What’s going to actually be needed to move from the existing baseline to the future desired performance? What does that mean in terms of what processes are needed? What does that mean in terms of various types of aspirational business capabilities? And what means are available to us to produce solutions that are going to help us bridge that gap?

10. Outputs of Project Vision Meeting

There are a number of key deliverables that come out of the project vision meeting. The first, of course, is the project vision statement. And as you can see on the example on the slide here, my goal here is to keep this very simple because we have a particular need or a business problem. We need to track and manage expenses. For example, my vision might be something as broad as develop and easy to use is an aesthetically pleasing instructor expense management system.

Notice I am not specifying all a list of features. I am not specifying a particular design or a particular technology. I’m describing what is needed at a high level. In addition to the vision, we also at this point want to get a formalized charter because we want to be able to form our team to be able to identify our product owner.

And in order to be able to effectively do that, we need an authorization to actually begin our work. Likewise, a budget needs to be approved at this time that helps to support the cost of the people and the materials that are going to be allocated to the project. And this particular budget is going to be managed really jointly between the product owner and us as the scrum master on an ongoing basis, with the intent being that we want to ensure that the money is being spent to drive the highest value outcomes for the customer.

11. Lesson: User Group Meetings

Once we have an established project, vision and business case, the next of the key meetings we’re probably going to get very heavily involved in is facilitating the identification of more detailed requirements through user group meetings, focus groups, and so forth. In this particular lesson, we’ll talk about how user group meetings work, how we identify and develop ethics and persona, how we identify more detailed user stories, and how we support the product owner in helping to prioritize the various user stories into a prioritized product backlog.

12. Create the Prioritized Product Backlog

After we’ve done our initial elicitation activities, eventually we want to be able to get to the point where we have a prioritized list of the product backlog of user stories and epics that the customer would like in an appropriately aligned and prioritized order. Now, technically, the product owner owns the product backlog and it’s really the responsibility of the product owner to ensure that the priorities in the product backlog reflect the needs of the business. That said, as a Scrum master, we are going to be actively involved in facilitating workshops for user group meetings, various types of focus groups to help us identify the features and desired benefits of the solution and to help the customer use good techniques like Moscow analyses, repaired comparisons, or 100 point method or canoe to be able to prioritize those in a way that will facilitate the creation of the prioritized product backlog.

13. Developing Epics

So one of the first things we’re going to do is we’re going to be working with users in various types of group meetings or other types of workshops to establish and define a series of Epics. Now, an Epic is a great big high level user story. What particular functionality or capability would the customer like? How do we write that down in a way that’s relatively easy to understand, that in fact actively will be estimable by the team? How much effort will it ultimately take to produce this? And it may then be broken down later on into more detailed user stories as needed. Epics are generally gathered in some type of workshop and usually the job of the Scrum master is to facilitate this workshop and enable the group to provide us good information about their requirements.

This could be a user group work meeting, a workshop where we’re actually writing user stories, various focus groups where we’re getting responses and feedback from customers to various types of prototypes or more traditional techniques like interviews and questionnaires. Regardless of how we actually elicit the requirements, eventually we have to be able to identify them and we have to be able to write them down.

We also can help the group to facilitate identifying various types of acceptance criteria. How would we measure whether or not this particular Epic or user story was effectively met and then helping the teams identify and prioritize the requirements and any risks that may occur associated with that? Now again, the product owner is ultimately accountable for the prioritized product backlog. But in order to actually identify the requirements and begin to do the prioritization activities, most product owners are going to lean very heavily on a skilled Scrum master to facilitate those sessions.

14. Epics & Personae

Now, the basic idea behind an epic or a persona is very straightforward. An epic is a simple story. What exactly would a customer or user like to have happen? And the persona describes how this would drive specific value for a particular type of stakeholder. So, for example, here we have Jim. Jim is a busy traveling instructor from Michigan, and Jim is fixed. But we’ll play with Jim for the purpose of a user of our expense system. He’s frequently traveling around the country to teach scrum to customers and needs to be able to quickly and easily report his expenses in a timely manner to ensure he’s reimbursed before his credit card bill arrives at the end of the month.

So he’s concerned about being able toa get the expenses into the system, and he’s very concerned about getting paid. And this makes a tremendous amount of sense. You’ll notice also there’s kind of an emotional component here. He gets frustrated when the bill arrives before the money does. So if that were you, you certainly would want the money to be able to pay your credit card bill. You want to make sure your expenses are reimbursed in a prompt and effective fashion. So the purpose of the system isn’t just to be able to submit expenses, but to facilitate a process by which we create cash flow for this poor instructor so that he can pay his credit card bill. So we want to think about the epics and the personas in terms not only of what the solution is, but what it means to that particular stakeholder.

When we run a user story workshop or other kinds of user workshop activities, we want to be able to get them thinking about the solution, both in terms of what it is and why it matters. How is this going to help them be successful in carrying out the work that they need to do?

15. User Group Meetings

In addition to broad-based Epics, you’re probably going to be asked to facilitate sessions to do what we’ll call a functional decomposition. How do we break down those Epics into more consumable user stories that may fit within a given sprint? Again, a user story describes the desired functionality for a particular portion of a system as well as the customers requirements in various forms. And again, it goes back back to the conversation we were just having about Epics.

I really want to be able to I’d list three things about the user story. Who’s going to use the system? What is this system being asked to perform, and why is this valuable to the customer? So the user’s story literally tells the story of why this enables the customer to be able to perform certain work that they want to. So there’s a language you can see associated with user stories and all the prioritized product backlog ultimately becomes is a dynamic list of user stories, risks and changes that have been prioritized based on customer value.

16. Writing User Stories

Now, in truth, you can write user stories almost any way you’d like, but one of the techniques I like to encourage people to use is to be able to follow a format similar to the one on the screen here. And again, you insert your role or persona there. I should be able to do some particular thing that I want to be able to do so that I get a benefit that I want to be able to get. So for Jim, our traveling instructor, he might describe this.

As a traveling instructor, I should be able to submit my expenses from my laptop through any Internet connection so that I can get reimbursement in a timely way. So we’re talking about who’s doing it, what they’re doing, and why they’re doing it. And if you think about their work, for example, as a traveling instructor, it’s understandable they want to be able to submit their expenses from a hotel or an airport wherever they happen to be at that moment in time to facilitate timely reimbursement.

17. User Story Acceptance Criteria

Each of the user stories that we write is somewhat subjective. After all, they want to be reimbursed in a timely fashion. They want to be able to submit their expenses. So one of the things we eventually have to do is to be able to lock down in a little bit more detail what in fact are the acceptance criteria by which we’re going to know whether in fact a particular user story is met by a particular solution. So, if you think about this in the context of testing and validation, I want to be able to validate that my solution in fact solves the problem. But I want to be able to measure that so that I can know for sure whether in fact it is met or not met, or in the Scrum language, is the user story effectively done or is it not done? So it’s the job of a product owner to be able to effectively define and communicate the acceptance criteria to the Scrum team. But again, it’s a useful role for the Scrum Master to play to ensure that the Scrum Master can effectively elicit those acceptance criteria from the customer as they’re eliciting the requirements for the user stories.

And then ultimately, it becomes very important for the Scrum Masters to then ensure that the acceptance criteria are held constant during a sprint. As you work your way through a sprint, the Sprint team is going to be working on a particular set of user stories. Each of those user stories have a defined set of acceptance criteria associated with their being done. It is essential that those acceptance criteria not change during the sprint. That doesn’t mean that we may not identify new acceptance criteria after we’re down the road a little bit, but that will be written into new user stories and needs to be dealt with in subsequent sprints.

So, as the Scrum Master, you certainly want to be able to establish objective measures for whether or not a user story is effectively done, because you want your team to be able to know in no uncertain terms whether or not it is that they have delivered on a particular user story. If they meet those acceptance criteria, the product owner needs to accept that as done. Now, that said, as they start working through various solutions, inevitably the product owner will find new things.

They would like new acceptance criteria, they would like to impose on the solution, but those need to be written new user stories and dealt with in a subsequent sprint. And it is specifically important that the Scrum Master protect the integrity of the Sprint so that the team doesn’t have moving targets within that short window. That said, they’re going to be moving targets in the broader window. That’s why we can write subsequent user stories and deal with them in subsequent sprints.

18. Lesson: Sprint Planning Meeting

In this lesson, we’re going to take a look at the role of the Scrum Master in the sprint planning meeting. Techniques you can use to facilitate coordination and communication between the product owner and among the various members of the Scrum team and how they put together and manage their sprint backlog.

19. The Task or Sprint Planning Meeting

The task of the Sprint planning meeting is run at the beginning of each sprint and it really consists of two main parts. The first of the parts is for the product owner to identify items that he would or she would like from the product backlog, and for the Scrum team to assess and hopefully include those in the Sprint backlog for that particular sprint. The second half of the meeting focuses on the tasks that will need to be done in order to produce and deliver on the user stories.

The job of the Scrum Master in the Sprint planning meeting, by and large, is to facilitate this conversation between the product owner and the various members of the Scrum team. The meeting is formally time boxed to one day for a four week sprint or 4 hours for a two week sprint and generally runs about 50 50 with 50% of the time focusing on which items from the product. Backlog would be included in the sprint backlog for this round and identifying in the other half of the meeting the tasks that need to be carried out, or at least the first stab of the tasks that need to be carried out for effectively executing the user stories.

The Sprint planning meeting begins with the product owner confirming the accuracy of the product backlog that it reflects the current price priorities of the business. From there, the Scrum team selects an item for inclusion in the Sprint backlog and may need to identify the necessary level of effort to perform the various tasks required to produce that user story.

20. Two Parts of a Task Planning Meeting

In thinking about the task or Sprint planning meeting. Again, it’s important as the Scrum master, to create a structure for a successful conversation between the product owner and the various members of the Scrum team. In part one, the product owner is going to suggest various user stories they would like for the Sprint, and the Scrum team then in turn needs to determine how many and which user stories it can deliver within that Sprint.

And they as a team need to come to a consensus on exactly which user stories they’re going to commit to for that particular Sprint round. The second part of the meeting then really focuses on how exactly it is that we’re going to carry out the work to produce those user stories, what tasks are needed to produce the various deliverables or product increments, and ultimately how do we estimate the level of effort involved and ultimately commit to those particular activities. So we think about Sprint planning meetings in terms of the user stories, we also think about them in terms of creating and estimating tasks that are going to be needed in order to carry out the work intended.