Level Set #3

Events - Basics

This article is about some basics in regards to Events. We will cover, mainly, the Sprint Planning and Daily Scrum events.

In the form of a quiz.

Let me reiterate. The quiz is given quickly, to a team. To be honest, there needs to be a discussion, and we hint here at some points for discussion, but by no means all.

It is expected that every Team will disagree with some of the things proposed here. They MUST disagree, otherwise they are not fairly choosing to do the other things they "agree" with.

We will discuss the Events in more detail later. This section is just the basics.

Sprint

• We will do 2-week Sprints. Regularly and consistently. With no space between sprints (eg, only rarely, and for special reasons, would we ever have an extra work day between sprints). Agreed?

Note: Of course, one, three and four week sprints are also permitted according to the rules of Scrum. We recommend faster feedback than 4-week Sprints. And we think we can do enough of working product in 2 weeks (that the business side or customers would want to review it), and that business stakeholders can arrange to show up regularly every 2 weeks (if the working product is sufficiently important).

Another key consideration: The Team can plan 2 weeks a lot better than they can plan 4 weeks.

Also, One-week Sprints allow very little recovery time for any mishap. And business stakeholders commonly are not able to come every week. God bless you if they will attend reliably for your Team.

• Key principle: The bad news doesn't get better with age. If we are off course, we need to know sooner. Agreed?

Sprint Planning

The first event within the Sprint is the Sprint Planning meeting.

• We will expect the Sprint Planning meeting (for a 2-week Sprint) to normally last 3 hours. Agreed?

The Scrum Guide gives a timebox of 8 hours for a 4-week Sprint, and thus 4 hours for a 2-week Sprint. We believe most Teams can quickly learn to do it well in about 3 hours.

Before the Sprint Planning meeting, the Team had a chance to re-estimate the Story Points on all the stories expected to go in the next Sprint. The PO, with the help of others, was able to do a decent job in gathering all the needed details.

Prior to Sprint Planning, the Team will have broken up stories so that each Sprint contains 8+ stories (that equals the average Velocity). And Stories will be roughly similar in size (eg, all 2SP or 3SP if the expected Velocity is 20SP.)

Also, we assume the Team has an average Velocity (the number of Story Points of done work per Sprint, on average, over the last 3 Sprints). Or, initially, has a reasonable idea what the Team's average Velocity will be.

Part One: Stories

• Part One starts with the PO articulating a Sprint Goal. Agreed?
• Part One is the Developers pulling in one story at a time, into the Sprint, or refusing a Story (typically due to dependencies or a lack of details for that story). Also, the total Story Points on "accepted" stories will be about equal to the average Velocity (as defined above). Agreed?
• The PO asks anyone at the meeting to clarify the Stories (or any related details). The Developers may ask questions and seek clarification. Agreed?
• The Team may find it needs to break up one or more stories further. The Developers may find that one or more stories need to be re-pointed. Agreed?
• They Developers may ask for additional advice or information about the work to be done. (They should have tried to anticipate any needs that could impact the story points.) Agreed?

As an example, Velocity is 20. Then "roughly equal" likely means we have four stories where each is 3 SPs, and another four stories where each is 2 SPs.

Again, some Teams will prefer to go for 10 or 12 or even more stories per Sprint. I propose 8 stories per Sprint as a minimum (for a 2-week Sprint), but fine if you want to go for more.

This is partly based on the Team learning to be good at breaking up stories into "sprint-sized stories." This is a skill set that beginning teams must learn.

• Principle: we want small pieces of work flowing quickly through the process. A key lean principle that supports focus, a sense of accomplishment, more transparency, and faster learning. Agreed?

• Part One should normally be done in 30-45 minutes. Agreed?

Part Two: The Team develops a more detailed plan of work for the Sprint.

• In Part Two, the Team creates a plan to turn these stories into working product during the Sprint. This plan is shown as the Sprint Backlog (aka Sprint Plan). Agreed?
• The plan is composed of the Stories (see above) and the Tasks (which are sub-tasks of the stories). Most tasks are estimated at about 2 ideal hours (for the person or persons who will do that task). Agreed?
• Part Two also includes a discussion of "how" we will do the work. And discussion of how the Developers will (or will not) help each other. Or whether others outside the Team may help a Developer or the Developers. Agreed?

Part Three: Commitment

• Part Three is commitment. This is discussed by the whole Team. The whole Team commits to doing that work in the 2-week timebox. Agreed?
• This commitment includes the commitment of the SM to help address relevant impediments during the Sprint and of the PO to answer questions relatively quickly during the Sprint. These are essential to the Developers (the whole Team, really) being successful. Agreed?
• Reliability. Once the Team commits, it is understood that the Team is expected to be relatively reliable in fulfilling its commitments. To make reliability concrete: the Team gets all 8 Stories done in 7 or 8 Sprints out of 10. That is the first reliability goal. Agreed?

Note: We will discuss later why we chose 7-8 out of 10 initially. And we would recommend a lower range of predictability later, for reasons that may not be clear now.

• Reliability. It is a key Scrum principle that Scrum should enable the Team to be relatively more reliable. Exactly how much more reliable depends on the circumstances of each Team. Agreed?

Note: To take a simple CYNEFIN example, Teams are sometimes in Complicated situations, Complex situations, and situations bordering on Chaos. Obviously, a typical Team is more likely to be more reliable in a complicated situation than in an almost chaotic situation.

• Because of the "chaos" in our work, we would never expect a Team to be more than 80% reliable on a per-Sprint basis. Albeit, even when a Team fails (by this measure), we would normally expect the Team commonly to be close to "complete" (eg, to have completed 7 stories out of 8). Agreed?

Scrum and Agile both talk about key principles of unpredictability and emergence over time. How relevant these are varies depending on the circumstances of each Team.

Again, Scrum and agile assume that, at least to some degree, with effort and learning, the Team can create more order out of the chaos of our work. And at least try to increase its reliability.

Daily Scrum

• The Daily Scrum is held every business day. Agreed?
• The whole Team attends the Daily Scrum. Agreed?

There is an argument that the PO may not attend sometimes.

• The Daily Scrum has a maximum timebox of 15 minutes. Agreed?

This rule is very commonly violated. Often a useful discussion about the root causes of the Daily Scrum lasting longer.

• The general purpose is to do a quick sync-up of the whole Team, get more Transparency, and then to Inspect and Adapt. Agreed?
• That is, normally, when team members start to really understand the value of the Daily Scrum, then everyone sees the benefits of the meeting. Although not necessarily every day does it person receive a clear benefit. Agreed?

Some will recognize (before) the Empirical Process that is partly explained in the Scrum Guide. We are not saying that the full inspection and adaptation always fully happens inside the Daily Scrum.

• One purpose is to enable anyone in the Team to emerge as a leader, and help the Team be more successful. Perhaps in a small way or on one issue. Agreed?

Such "emergent leadership" can happen quickly inside the Daily Scrum, or can happen later, or in another meeting. But the idea is that some or all of the key information became "visible" initially in the Daily Scrum.

We recommend the following specifics. Each person answers the so-called 3 questions. A person should say whatever is most useful to the Team, and say it briefly. So, the 3 questions are only a guide.

• Question One: what did you do (work on or finish) yesterday? Agreed?
• Question 2: What will you do (work on or finish) today? Agreed?
• Question 3: What is your biggest impediment? Agreed?
• The whole situation is not perfect. Each person is not perfect. So the person is not just answering about the 1-3 tasks right now, but about the person's or team's ability to complete the work of this Sprint. Agreed?

And, the last question (biggest impediment) is not whether we will complete our commitment this Sprint, but what is the top "thing" holding us back from being "perfect".

• The Team may briefly decide the biggest impediment right now. Agreed?
• If there is time in the 15 minutes, the Team may discuss one or two impediments. Briefly. Agreed?
• "After-Party": One, two or three people from the Team may "stay back" after the Daily Scrum and discuss or work on the Top impediment. Typically these would be: The SM, the person who knows that impediment the best, and maybe someone who would be good at working on that impediment. Otherwise, Team members return to work right after the Daily Scrum is over. Agreed?

Impediments

A few notes on impediments.

• An impediment can be anything that holds the Team back (eg, reduces our productivity), or good things that can be added that would make the Team better. Agreed?
• An impediment can be some version of "I suck, we suck, or they suck." Agreed?
• Impediments are anything that is imperfect. So, we always have impediments. Agreed?
• Often impediments are initially identified as big things (eg, we need to implement automated testing), and have to be broken down into things that can be done inside a Sprint. Agreed?
• An impediment can be fixed by the SM, the Team (usually 1-2 people working inside the Sprint, but also could include the PO), by the Manager, by another person or group outside the Team, or, for example, by a vendor outside the company. Agreed?
• Impediments can be identified at any time. Ex: Given to the SM. Agreed?
• Considering the Scrum events, impediments are more commonly mentioned in the Daily Scrum and the Sprint Retrospective. Agreed?
• Some impediments can be easy to fix, but it is common that impediments can be hard to fix. In fact, sometimes the organization will not agree to fix an impediment. Expressed too simply, the impediment with the best ROI (benefit over cost) would be fixed first. Agreed?

Other factors might include risks, dependencies, political considerations, timeliness of delivering the current release, etc.

• Principle: Fixing impediments is essentially the classic continuous improvement idea. In Lean it is famously called Kaizen, a Japanese word, that in many business books is translated as continuous improvement. So, we want to do it every day, every sprint. Agreed?

The Meta Situation

Socrates always liked the Q&A, the dialogue.

The first thing is not that you agree with my answers. The two first things are:

(a) did you become conscious of the question or issue?

(b) did you consciously, thoughtfully, decide how to address it?

And, I mean, as a Team. But you could be thinking of this from one person's viewpoint.

Closing

Please give your feedback on these questions.

Again, to keep it short, I did not discuss all the possible answers. Nor describe all possible situations.

So, some Teams will not agree to specific things. But might well agree to some variations of what is proposed above. Often these variations are to me minor. Or, they might disagree totally on a specific item.

What is important is that they use the questions to think through what their way-of-working will be.

If they agree, and play the same game, and try to improve (or ask others to help them improve), we have high confidence they will improve. Will be more successful.

More to come.