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

21. Planning Poker

There are a number of different techniques that you, as the Scrum Master, can bring to the team to help them assess things like level of effort associated with a particular user story. One that I suspect you’ll be using for most sprints is called Planning Poker, and in Planning Poker, you’re going to provide a deck with three cards to each of the members of the Scrum team SM and L for short, medium, or long. Level of effort. Once the product owner has selected a particular user story and presented it to the team for consideration, you’re going to ask the Scrum team to assess the relative level of effort associated with that user story.

Generally speaking, the team’s going to have a whole lot of questions for the product owner, and they’re going to continue to ask and answer questions to try to get as broad an understanding as is necessary of that user story and what it means. And then you’re going to ask each of the team members to pick the card that you think reflects the level of effort for that story. If the majority of the team selects the same card, that will probably give you a pretty good idea about the level of effort that will be intended. Occasionally you’re going to have outliers. And you should invite them to explore why they came up with a different level of effort, why they think it’s easier or harder than the rest of the team members, and then continue to repeat the processes necessary until you have an agreement or a consensus that you can reach about the team.

22. Fist of Five

There are other mechanisms you can use as you’re working your way through these discussions to help drive consensus on your team. And you may run into this through planning poker, through the number of user stories that are going to be included in a sprint or what have you. But after a certain discussion, you may wish to get a sense of whether people are bought in general agreement on the direction the team is going. So one of the techniques to do that is called Fist of Five. I’m going to ask people, based on their current conversation, to be able to put up to five fingers.

 If they put up all five fingers, they’re saying, I wholeheartedly agree with the group’s conclusions. I’m completely bought in agree with what the group is doing. On the other end of the spectrum, one says, I disagree with the group’s conclusions and I have very big major concerns that need to be addressed. And of course, there are gradations between that. At level two, I disagree with the conclusions and I’d like to discuss the minor issues. At level four, I agree with the conclusions, but would like to discuss some minor issues. And at level three, I’m not so sure.

So I’m going to go with whatever the group’s consensus conclusion is. So by doing fifth to five, you get a general sense of where the group is. Are the group generally in agreement where there are certain issues that need to be worked out? Is the group generally in disagreement? In which case we may have a whole lot of facilitation to do to try to figure out what needs to happen from there? Is there a lot of ambiguity? If I see a whole lot of people with three, then I’m deeply concerned that people don’t fully understand what’s going on, in which case there may be a lot of risk associated with that particular user story.

23. Points for Cost Estimation

When we consider the level of effort associated with estimation, whether we’re talking about estimating costs or estimating the level of effort for an activity, sometimes it’s very difficult to get exact information about money, for example. And so what we want instead is a language that we can use to describe a relative level of effort or a relative level of money. Is this really expensive of is this really cheap and easy? Is it somewhere in the middle? Okay. And so rather than trying to deal with exact dollars or exact numbers of hours of effort for something, one of the techniques we encourage Scrum masters to use is the technique called story points.

And the idea of story points, they can be used to measure at points of cost. They can be used to measure points of effort. But what we want to be able to describe is for a particular user story about how big a job is this? o to be able to do this successfully, you would need to benchmark. You want to be able to establish some particular benchmark that is well understood by all of the members of the team and perhaps give that benchmark, whether we’re talking about cost or whether we’re talking about effort, a level of ten points.

So this is ten points of effort for this particular user story. So that allows us to size, roughly speaking, a particular level of work, something’s about half that, and it’s about five points. If something’s twice that level of effort, it’s about 20 points. And that helps us assess, for example, about how much the team can bite off in a particular sprint over time. Story points are particularly helpful in being able to assess things like velocity, how efficiently the team is able to work their way through user stories, and to be able to convert story points to done levels of user story.

24. Other Estimation Techniques

When we consider the level of effort associated with estimation, whether we’re talking about estimating costs or estimating the level of effort for an activity, sometimes it’s very difficult to get exact information about money, for example. And so what we want instead is a language that we can use to describe a relative level of effort or a relative level of money. Is this really expensive of is this really cheap and easy? Is it somewhere in the middle?

Okay. And so rather than trying to deal with exact dollars or exact numbers of hours of effort for something, one of the techniques we encourage Scrum masters to use is the technique called story points. And the idea of story points, they can be used to measure at points of cost. They can be used to measure points of effort. But what we want to be able to describe is for a particular user story about how big a job is this? So to be able to do this successfully, you would need to benchmark. You want to be able to establish some particular benchmark that is well understood by all of the members of the team and perhaps give that benchmark, whether we’re talking about cost or whether we’re talking about effort, a level of ten points.

So this is ten points of effort for this particular user story. So that allows us to size, roughly speaking, a particular level of work, something’s about half that, and it’s about five points. If something’s twice that level of effort, it’s about 20 points. And that helps us assess, for example, about how much the team can bite off in a particular sprint over time. Story points are particularly helpful in being able to assess things like velocity, how efficiently the team is able to work their way through user stories, and to be able to convert story points to done levels of user story.

25. Use Index Cards

One of the things I’m going to encourage you to do as a Scrum master is to take advantage of simple, agile practices in how your organization writes user stories, writes tasks, and so forth. Generally speaking, I either use small index cards or even larger sticky notes to actually capture and document information about user stories, about tasks, about other kinds of information we want to document, meant the user stories themselves. Again, generally written on small cards. The focus is on the essential details. It is entirely appropriate where necessary, to have other documentation available business rules, process flows, if that’s useful, right?

But for the purpose of kind of getting organized around which user stories we’re going to focus on, we’re going to focus on information and we’re going to keep the focus very explicitly on the stories themselves and on the key acceptance criteria. This will much more effectively facilitate the collaboration and discussion about sizing and effort. It will improve overall visibility and transparency, especially when you then use these on a tool like a Scrum board. And then we can use that in a way to help assess and identify potential risks, identify potential problem issues associated with timeline, availability of resources and other kinds of things that may impact the ability of the Scrum team to deliver that user story.

26. Decomposition

One of the key techniques that you’re going to use throughout Scrum is a technique called functional decomposition. Now, we talked about this a little bit when we were talking about user stories and epics. Usually when customers are describing things that they want, they kind of start with big picture ideas around goals and objectives and various functionality they might like. And we may need to then break that down into specific user or stories that describe specific pieces of functionality we can deliver as a development team in a particular Sprint.

Now that we’re into the actual Sprint planning, we may need to do further decomposition of those user stories or during the task phase to be able to take the user story and then decompose it into specific tasks. What? Development, testing, refactoring, and so forth. We’ll need to get done in order to successfully produce and deliver that particular user story. We want the user stories to be sufficiently decomposed to allow the team to actually create the successful deliverable during the sprint window and to be able to carry out and execute the tasks that are identified during the task phase.

27. Determine Dependencies

Once we’ve identified the tasks that are needed to produce the user stories, we now need to take into account some reality checks. Are there certain technical considerations, people considerations, or other dependencies that may prevent us from being successful? These really get broken into four main categories. So a mandatory dependency is something that cannot be helped. This must occur before for this other thing can occur. Lots of these are logical.

So I have to write the code before I can test the code. I have to actually write and test the code before I can fully document the code, and so forth. Discretionary dependencies might be for convenience measures. So maybe I want to complete these pieces of work before I do this piece of work over here, because it makes this piece of work more efficient to do.

So there may be some convenience reasons, for example, why I might choose to do certain tasks ahead of other tasks. Some dependencies may be external to our particular scrum team. They may be driven by policy. They may be driven by dependencies on deliverables coming from some other team.

They may be dependencies based on organizational constraints, legal and regulatory requirements, and the like. And so where those exist, they may impact, for example, which user stories we can effectively work on during this particular sprint. Lastly, we may have certain internal dependencies which team members will be available, are certain people going to be away on vacation for multiple days? And so those internal dependencies may impact the velocity of the team in that particular sprint.

28. Establishing Estimation Criteria

So when we think about the work that’s happening here during the task estimation portion of the Sprint planning meeting, you want to think as the facilitator here. How in fact is it that I can make it easy for the team to come up with a way to estimate effort that’s reasonable and consumable? Most of the time they don’t have detailed information on costs. Most of the time they don’t have detailed information on exact number of hours it’s going to take to do something. And so what we want to do instead is substitute certain types of relative measures that allow us to get decent ballpark figures. We can use story points, we can also use the idea of ideal time.

If I had no other things to do and I could just focus on this one thing, how long would it take me to do that? Understanding that that might not be real, right? Because there may be many other things they also have to do, but if I had ideal time to dedicate specifically and only to this, how long would that actually take me? And so by using relative criteria, it helps us avoid having to do a lot of reestimation. It helps us avoid large scale misses in estimation most of the time, especially if you have the team collaboratively working on this. But that said, it allows us to start to size the necessary level of effort and to figure out about how much the team can effectively deliver in a particular period of time.

29. Creating the Sprint Backlog

Eventually the key output from the sprint planning meeting is the Sprint backlog. For that particular sprint, the backlog is going to take the inputs from the committed user stories as well as any requested and approved changes, identified risks, and the effort estimated task list. And then simply what we’re producing in the sprint backlog is a list of user stories that we’re going to work that sprint. Okay. We can then use a scrum board to get organized about. Given a particular set of user stories, exactly which tasks need to be carried out to produce and deliver on that.

30. Scrumboard

So here’s a simple example of a Scrum board. And so in thinking about managing and supporting your teams, one of the things you want to create is broad-based transparency and visibility into the activities of the team. And so a Scrum board allows anybody looking at the team or coming into the war room to be able to gauge the process and the practices of the team in working the user stories. So in this particular example, I have a set of user stories in the left hand side, okay? And each of those user stories may be weighted according to user points.

So I may have eight story points for the first one. I may have five story points for the second. That then leads to a whole level of different types of to do items and tasks that have to be done to carry out and deliver on that user story. And you’ll notice that there are many different Suds code, this test that write documentation for these things, and so forth. As people take certain tasks and begin to work on them, they move them over into the in process section. You’ll notice at that point we have effort estimated for that particular activity.

And you’ll notice also that we’ve attached some initials to this. So somebody’s taken this particular assignment and has started working on coding DC. Meanwhile, somebody else named SC is actually working on testing some other thing. And you’ll notice they continue to work their way to the right through verification and effectively to a done task. All right? So I can use a Scrum board to track and manage how the various tasks being carried out and by whom. So I can see at any moment in time which particular things DC and SC are working on. And I can see which things are done and which things are still to do.

31. Sprint Burndown Chart

Another tool the team can use to help track and manage its progress is what we might call a sprint burn down chart. Now, here you’re tracking for the number of days in the sprint overall, the amount of work hours that are going to be expected to deliver the goods within the particular user stories. And then as we work our way down through the hours, how many hours are actually being consumed assumed by the team at various stages and of days, and how are we doing in terms of burning down the various user stories and tasks that have to get done in order to produce the results. And so you can see on a day by day basis, we can track and manage the amount of remaining work. We can track and manage where we are relative to the baseline and that we can see whether or not we’re to run into potential obstacles that may impact the ability of us to deliver the results for that. Sprint.

32. Velocity

There is much confusion in the Scrum community about the notion of velocity. Velocity is important. I want to be able to track and manage for a particular sprint about how many user stories or story points are we able to effectively deliver. And I would like to get to the point where we gain sufficient levels of efficiencies over time that the team’s performance improves and that we can deliver more story points per a particular time as we get a little bit better in doing certain kinds of things.

That said, Velocity of course is nowhere near as important as whether we’re in fact delivering appropriate value back for the business. This is a planning tool mostly for the product owner and thinking about things like a release plan. So if I have a release plan that requires us to do 90 story points before we’re going to reach minimum functionality, and we’re doing about 30 story points each sprint, then I could probably make a rough order of magnitude. Guess that it might take about three sprints for us to get to that minimum level of functionality and I can use that to plan my release accordingly.

That said, I want to ensure that we’re not using this as a tool to flog people, because in many cases when we do initial levels of effort, especially when we have a new team, it’s hard to assess exactly how many story points we really can deliver. And ultimately, do we have the right number of story points identified for a particular work product that we’re trying to deliver. And so Velocity is somewhat of an imperfect tool, but allows us to have some loose capability of doing release planning based on what we’ve been able to deliver in previous sprints.

33. Sprint Tracking Metrics

As the Scrum Master, you’re going to be asked during the Sprint Retrospective to share some feedback with your team about their performance that round and to be able to help tie together what they’ve been working on to valuable things that the customer will consume. So we want to be able to track certain kinds of things relative to each particular Sprint. Some of the ones I encourage you to track the business value delivered delivered. So, in other words, the value of those user stories as weighted from business metrics and business perspective.

Where possible, I like to go for really big business metrics like revenue, profit, market share, compliance, those kinds of things. Ultimately, we can take more operational looks at metrics as well the number of user stories delivered in a particular sprint, the number of story points delivered in a particular sprint, and whether that’s leading to an improvement in our organizational velocity. Are we able to produce more story point value per particular sprint window because we’re getting more efficient as a team together.

34. Outputs from Sprint Planning Meeting

The outputs from the Sprint planning meeting themselves are in fact the things that really fill the Scrum board. The various user stories that are going to be committed by the team for the sprint, an effort, estimated task, list of tasks to do, the actual backlog of activities we’re going to engage in in that sprint and the approval from the product owner that that is, in fact, the set of user stories that the team has committed to notice that the final decision of which particular scrum user stories are going to be delivered in that particular window, in that particular sprint, comes from the team. The product owner may not dictate that you’re going to get these X number of user stories done this time.

It is the job of the team to assess the size and scope of what can be delivered within this print window and ultimately to make commitments that they believe are achievable based on the customer’s requirements. If you have product owners who are trying to jury rig what the Scrum team is going to agree to, they’re going to become discouraged very quickly because they’ll know that they are in fact not getting to be self-directed and self organizing.

They’re in fact being dictated to by somebody else. So as someone who’s going to coach and inform people about Scrum practices within the team, it’s your job as the Scrum master to protect the team’s decision making about what’s achievable and to foster an environment where the team is responsible and accountable for the choices that they make during their Sprint plan.

35. Lesson: Conducting the Daily Standup (or Daily Scrum)

In this next lesson, we’re going to talk about the role of the Scrum Master in helping to facilitate the daily standup meeting or the daily Scrum. Again, it’s important to remember as we start talking about these things, that nobody in the Scrum team has positional, authority.

If you’re the Scrum Master standing with the rest of your Scrum team, they’re an equal team with equal weight. And you as the Scrum Master are not a project manager dictating to them and they are not reporting to you, but to one another.

36. The Daily Standup Meeting

The purpose of the daily standup meeting of course is team communications. We want to ensure that the team has broad awareness of what the rest of the team is doing and that you as the Scrum Master have awareness of places where the team may need your help. The meeting itself is a very short daily meeting of 15 minutes duration and that is rigorously timeboxed. And I encourage you very much to hold the team to that 15 minutes. All of the team members are expected to attend, but the team meeting has to proceed even if anyone has to miss.

We want to be able to use the meeting, to be able to report progress, to be able to explicitly plan the day’s activities and where necessary to encourage certain types of discussions. That said, I would suggest that most of those discussions actually happen in sidebars because the team and the meeting is so tightly time boxed.

As the name implies, this meeting is intended to be done standing up. This will encourage people to honor the 15 minutes time box. And our job as the Scrum Master is to facilitate this meeting. Especially to encourage people to treat all of one another as peers. They are not reporting out to you or the product owner or anything anybody else, but they’re reporting to one another about the status of their activities.

37. Three Daily Questions

During the daily standup, you’re going to instruct each of the members of the team to ask and answer three questions what did I complete yesterday? What will I complete today? And what impediments or obstacles am I currently facing? I encourage you to train your staff that the first two questions should be quantitative. If possible, try to keep it short if they’re going to be lengthy and qualitative.

Answers to encourage those to be discussed in more detail in a sidebar is appropriate for the third question if there are impediments or obstacles to be dealt with, in many cases, they’re building an action item list for you. And the job of the Scrum master, by and large, is to support the team by helping identify ways to help deal with some of the impediments or obstacles the team may see to their success.

38. The War Room

In general, Scrum teams work much, much more effectively if they are colocated. It is not impossible to run a team that’s virtualized, but it is very, very helpful to creating the kind of collaborative environment that you want to have colocated teams wherever possible. And I don’t just mean colocated as in they’re all in the same building, but really being together generally in the same room. In many organizations, of course, what’s happened is either the organizations have designed specific spaces to support war room and collaboration type activities like this, or they have commandeered various conference rooms and effectively turned them into work rooms so the teams can effectively be together and work together.

You want to have an environment that makes it really, really easy for people to get around and talk to one another, that encourages behaviors like pair programming, that allows everyone to be able to readily see information radiators like a Scrum board or a Sprint breakdown chart, to be able to take advantage of agile and simple tools like index cards and sticky notes and ultimately to create an environment where work is actually taking place and where there tends to be some bustle and some energy going on because people are collaborating and working together to produce effective solutions.

39. Outputs from Conduct Daily Standup

There are a number of key things that we’re trying to deliver out of the daily standup meeting. If there are particular issues or impediments to people’s progress as the Scrum Master, we want to know about that as soon as possible so that we can get after trying to find ways to deal with those impediments and obstacles to improve the performance of the team.

Likewise, we want to facilitate communications among the various stakeholders on the team about tasks and activities and potential dependencies. And so the daily stand up is usually where we drive updates to the burn down chart, any impediment logs, changes in the Scrum board, any change requests that were unapproved, any risks that have been identified or mitigated, as well as any new dependencies that have been identified as the Scrum Master. You’re trying to create safe space for your team.

You want to be able to use Scrum practices to drive improvements in their morale and to improve top level performance and motivation for them in carrying out their work. One of the ways that we do this is by giving them some autonomy, giving them some controls, allowing them to adapt and really practicing the activities behind self organization that each and every member of a Scrum team is very important. And that by enabling the teams to figure out together among themselves how to organize and manage the work to deliver the results, you get dramatically enhanced levels of performance. By establishing good practices like pair programming, constant refactoring and continual integration, integration of solutions, you’re going to get a higher quality solution coming out as well.

40. Lesson: Grooming the Prioritized Product Backlog Meeting

In this next lesson, we’re going to look at how the prioritized product backlog gets groomed by the product owner during the sprint. And one of the jobs that the Scrum Master is clearly going to be asked to do is to help facilitate any changes, risk identification activities and things that are going to affect the prioritization in the product backlog and really getting ready for subsequent sprints. Let’s look at the role the Scrub Master plays in helping to support the grooming activities.