Level Set #4

Introduction

We have done three prior posts in this series.

This is the fourth. You may want to read the earlier ones first.

This one (#4) is about the other two events (or meetings) in Scrum.

Earlier we covered, at least first pass, Sprint Planning and the Daily Scrum.

Now we wish to cover:

• Sprint Review, and
• Sprint Retrospective

Pardon: This is my first version of this post. I have tried to proofread it. It's pretty good, but I am sure I will want to make changes later. Your feedback in the comments will help (whether about "typos" or something more substantial).

Sprint Review

This meeting is timeboxed at 4 hours for a 4-week sprint and 2 hours for a 2-week Sprint.

The meeting occurs at the end of the Sprint, just before the final thing, the Retrospective.

• Agreed?

Attendees and Purpose

The whole Scrum Team (I assume 7 people) should attend, along with 4 Business Stakeholders. So, a total of 11 people.

• Agreed?

Your organization often uses "Business Stakeholder" already, so let's give it more definition here.

For now, a business stakeholder (BSH) should represent the customers (or a key customer set), and how they will see business value and also how the customer will want the details to work on a specific user story.

This is demanding. Some BSHs are great at the high-level business value. But no close enough to understand the details. Other BSHs are maybe younger, and understand the details of the feature (story) well, but often lack the perspective to comment much on business value.

• Agreed on BSHs?

The meeting has two purposes:

• To review the Sprint and inspect and adapt generally about what to do next.
• To provide a good "demo" of what has been built so far, and get good feedback on each item. So that, if an item is fine, this means that it is approached "to be released", and at least the notion is that no further approvals are needed.

You could add three purposes, or rephrase the second purpose in these ways:

• Learn, from what we have built this Sprint, what the customer will like and will not like.
• Identify the "bad news" (which stories need more work).
• Assure that the "bad news" does not get better with age. At least attempt to fix any bad news as cheaply as possible (eg, while the Krispy Kreme's are still fresh). Or, for some we say: fix the story while the knowledge is still fresh in the heads of the developers.
• There can be other learnings; these are the most common ones.
• Agreed on the 6 bullets above?
• Agreed on everything said so far about the Sprint Review?

Pause. Reminder.

I remind the reader that I am giving some detailed specifics.

I am NOT requesting that the TEAM answering this survey agee with every detail.

I remind you: until I see how you implement things in the details, I am not sure that you understand what you are agreeing to.

And: You must disagree with the recommendations here some. If not, you are not thinking. If not, then you are not molding the way-of-working to fit your own particular Team situation.

Suggested Organization

We suggest that the Sprint Review be first thought of as having two sections.

1. the Review part
2. the Demo part

In the review, the PO stands up and says (a) this is how it started. We committed to this Sprint Goal (describe it). We committed to 8 stories [a fairly quick listing of the stories., with these 8 user stories. And the total was 20 story points. (And our average Velocity at the beginning was 20 SPs.)

And says (b) this is how it's going at the end of the Sprint. Example: "We completed the Sprint Goal, we completed all the stories, and in fact one additional story, so the Velocity for this Sprint was 22SPs."

"I assume we want to continue the Team for the next Sprint. Any other discussion? Everyone happy with the basic direction?"

Then someone stands up, probably the SM (ScrumMaster). "Business stakeholders: Here are our top 3 impediments. Impediment A, which is [blah blah blah]. Impediment B, which is [blah blah blah]. And Impediment C, which is [blah blah blah]. Are you interested in investing to fix any of these impediments?" (Investment could be money, time from some people, or "political capital" to get change to happen.)

One answer is "No." Then we ask why. The BSHs explain that another team is having more problems than your Team, so we don't have time to help you this Sprint. Another answer is: "Yes." The BSHs explain that they would like to help with Impediment B. Another possible answer is: "Maybe."

"Maybe" usually means that the BSHs need to hear about the benefits of fixing, and the costs to fix, each of the three impediments. Often we have to do some prep work on the benefits and costs, and then we have the meeting to discuss and decide about any investing in fixing an impediment.

Note: This suggested dialogue gives you at least some idea of how the meeting might go, and what kinds of things might be discussed. Obviously, there are many other possible scenarios.

• Agreed on this approach to Part 1 (Review)?

Part 2 is the demo and getting feedback from the demo. We show the working product.

The main thing is feedback. But let's divide that into some parts:

• The feedback should be complete. For these 8 user stories we do not want to get any feedback on them later. (Of course, late feedback will still happen, but, more than before, we want all the feedback now.)
• The feedback should include positive feedback, just like we get every 2 weeks in waterfall. (Ok, sarcastic.)

The positive feedback could improve the morale of the Team. That morale boost could make them more productive.

• The feedback should include negative feedback.

The key principle is: "The bad news doesn't get better with age." It is cheapest to fix things now.

To be honest, this is hard, because it is really feedback about whether the customers will like it for the whole lifecycle of the product (over years, even decades).

• The negative feedback should not be delivered as a personal attack on the developer(s) involved. Nor should it be taken personally or as a personal failure.
• We should get feedback on the Business Value of the story. Is it more or less than we expected (when we imagined it with a story card and some details)?
• We should get all the details now, of any changes. There is no cheaper time to fix this story (which will happen at the very beginning of the next sprint). So we need the details of any changes now. Text the SME!
• Agreed on these last 6 bullets (re Part 2)?

Part 3 is the Summary.

• We identify the new average Velocity (over the last 3 Sprints). Let's say the average at the start of the Sprint just ending was 20SPs. And let's say the average now (including the Sprint just ending) Velocity = 21SPs
• Then, how many SPs to fix the 3 stories that need to be fixed? Let's say 2SPs.
• That leaves 19SPs open for new stories in the Sprint just about to start.
• Agreed on these bullets for Part 3?

The Cost of Weak Communication

• One cost of the ineffective communication is that we have to fix the stories in the next sprint. In this example: 2 SPs.
• Another cost is the effort the Team wasted in the Sprint just ending. Commonly that would be about the same amount. In this case, another 2 SPs.
• So, in total the loss caused by poor communication was 4 SPs. The expected Velocity was 20SPs. So, we lost 20% of that expected Velocity.
• So, we would expect that everyone would agree to try to communicate better, with the expectation that the loss can be reduced (eg, to only 10%).
• Agreed...on the bullets under Weak Communication?

The Sprint Retrospective

Purpose: To do the empirical process (transparency, inspect, adapt), and to make some continuous improvement happen. The improvement, from this meeting, is not for the Product directly, but - to use another P-word - for the Process. (To me "process" is too limiting, but ok for a quick catch-word.) To make the Team more effective in some way.

So, the point of the Retrospective is to enable us to all work together to help make the Team better.

The hypothesis is: If the Team is better, the Team will more effectively deliver more or better Product to the customer.

Normally, we hope this improvement will show up first as increased Velocity for the Team. But improvement might be measured other ways.

• Agreed?

Timing: The Scrum Guide sets a time-box of 3 hours for a 4-week Sprint, and so 1.5 hours for a 2-week Sprint.

Who Comes: The whole Scrum team. In my example, 7 people. The Developers, the SM, and the PO.

Key Dysfunctions: It is common that people complain a lot. Too much. But, it is useful to complain some, so that we understand our situation better. But we cannot spend the whole time complaining. Nor even spend the whole time talking.

It is also common in a Retrospective that people work on a lot of things, and get nothing "over the goal line." So that no real progress, or very little progress, is achieved.

Yes, many and maybe most impediments can't be fixed in a 7-person meeting. But, we recommend making serious progress on only one Impediment, together as a Team. Everyone contributing. As much progress as we can make in the time-box, and likely the SM with others will continue making progress on the impediment during the next Sprint. Hopefully the impediment (or its "solution") has been made small enough, so that we can complete that solution in the next Sprint with some room to spare.

So, not a lot of talk about multiple solutions for multiple problems, and we really get nowhere. Focus more on one problem, and get it solved (or mitigated) quickly. And start receiving the benefits from the solution.

• Agreed?

We propose the following process for the meeting:

• We each identify, on stickies, one positive thing that happened. Every person does this. And we share that.

Results: We all see that more positive things happen that we had been aware of. Everyone gets ideas of something positive they could do more frequently (or start doing). This is good.

Impediments can commonly be described with a sentence that starts: I suck, or we suck, or they suck, or it sucks.

• Next step: All 7 people each have to write three stickies (from the four "I suck" statements above).
• Next: We review the existing Impediment List briefly.

Specifically, we have 20 items on the "Top 20 Impediments" list. These are things that have not been fixed yet.

The list is prioritized, mainly by ROI (benefit/cost). Although other factors can be involved. (The Impediment List will be discussed more later.)

• Next: We identify any of the new impediments that should be added to the Impediment List. Commonly a few new ones are added (and so some also come off the Top Impediments List too).
• Next: The SM Report.

The SM takes 10 minutes to explain what he/she has done during the Sprint. Kind of like a SM "demo." Which impediments did you fix or arrange to get fixed? What proposal did you make to a manager? That the manager approved? And, after everything, how much did the Velocity improve (possibly starting the next Sprint)? (We are hoping an average of 1SP / Spring improvement, starting from a base of 20SPs.)

The SM Report enables the SM to learn how to explain their value to the Team, to a skeptical audience, so that they are appreciated more. It also gives the SM feedback, so he/she can see how the SM may need to speak or act differently.

Later, having learned to explain their value to the Team, the SM can advocate their value to a Manager(s) better. This, I think, is a crucial need. A lot of Managers do not recognize the value of the SM in the way they should. (Although the root cause may be that many SMs do not know how to deliver the kind of value that would justify their cost.)

• Identify the Top 4 Impediments.

This is simple. The people should probably spend most of their time working on the top impediment. But it is possible the top one is quite small and easily dealt with.

Also, the SM will be driving getting the top impediment fixed (by someone), and might complete the top 2 or 3 during the Sprint, and have time to start the 4th impediment. Given that, the Team should have a say on the "order" of at least these top 4 impediments (order mainly by ROI, but other factors as well).

• Work together on the Top Impediment

We recommend that most of the time of this meeting be spent working together on the impediment and, with all due speed, toward completing a solution. Implementing and getting the expected results (we hope).

Later we will give more suggestions about how to work together and what to work on.

• Agreed?

Notes: We do not recommend "rushing" to a solution. At the same time, it can be true sometimes that the problem is clear and the solution is clear, and "all" we have to do is implement the solution.

The Team must balance: are we going too fast or too slow? I think I'd recommend commonly going faster and breaking things. And learning from that. Rather than going slower. Why? Everything we do is imperfect. We have many things to fix. So, don't spend too much time on one thing. We commonly do not know whether our solution will work, or give us the expected benefits. So, learn faster from acting quickly.

• Agreed?

Closing

Once we introduce other elements, we will have more quiz questions about these two events (meetings).

By asking these questions, we tried to make clear the thought process the team should use to decide on its own way-of-working.

Often they need a coach or guide, someone independent, who can explain these suggestions and the principles behind them. And can help them customize their way-of-working more usefully to their particular situation.

Again I say: No Team will ever do exactly what is "recommended" here. First, I personally have never seen the "perfect" situation where all these decisions (recommendations) would be appropriate. But, more to the point, every person and every team and every company is "now" at a different place. And, to some degree, has a unique business and unique customers. So, it MUST be customized.

The detail of the suggestions enables the Team to think through the decisions it must make.

One result, as an example: they often suddenly see that being agile requires much more discipline than doing waterfall.

I hope this quick survey (along with past surveys and future ones), will enable your Team to start (or restart) a process of continually improving the Team. And delivering more Business Value (as you define it) to the Customers and for the Company.

The Team, the Customers and the Company all must win.