Agreement Builder — Most Typical Agile Workshop Ever

Use this simple recipe to effectively facilitate the most common workshop in the Agile world

Let me guess: you’ve been making lists. A lot of lists. Not the “buy-groceries-don’t-forget” kind of lists. The ones you create together with your team. Think of it: Definition of Done, team’s ground rules, coding standards, something more exotic like Delegation Board, you name it. These are all in essence lists. (OK, the last one is a matrix, but for our purpose, it’s convenient to treat it as a list.)

In the Agile world, decisions driven by group discussions are quite common. After all, face-to-face conversation is the most effective method of conveying information [1]. Often the outcome of these discussions is a list. However, this is just a form, not the goal. The goal is to build a written agreement. From my own practice I’ve created a workshop structure that effectively leads a team in reaching this goal. I call it Agreement Builder.

Structure

A one-hour timebox is a good fit for this workshop and one session is enough for most topics. Keep the workshop within these boundaries otherwise the group will lose focus. Of course, there are exceptions but more on that later.

The structure follows the Diamond of the Participatory Decision-Making defined by Sam Kaner [2] and can be divided roughly into five stages. The names of the stages coincide with the retrospective stages defined by Esther Derby and Diana Larsen [3]. It’s intentional so that it is easier to draw analogies to a retrospective session.

Preparation

Before we go into the workshop structure, it’s important to note the preparation. Talk to the whole group or to each participant if necessary. Together align on why you are doing the workshop — the purpose, and what the group wants to achieve in the end — the goal. For example, the purpose could be to improve communication in a team and the goal — a set of ground rules.

Stage 1. Set the Stage

This part is quite simple. Reiterate both the purpose and the goal of the session. Explain the facilitation techniques you are going to use. This will ensure a smooth flow throughout the workshop.

Stage 2. Generate Ideas

Recommended techniques: small group discussions, individual writing, round-robin, stacking, or 1–2–4-All.

At this stage, the goal is to generate the basis for the resulting list. Any technique for generating ideas will work here and I usually timebox this part to 7 minutes. My preferred technique is small group discussions — break up the group into pairs or trios and let them discuss. Other alternatives could be stacking (participants speak one by one in the order predefined by a facilitator [4]) or 1–2–4-All from Liberating Structures. If the environment doesn’t permit group breakouts, e.g. in an online meeting without the proper tooling, individual writing could be an option. As a result, you get a bunch of stickies with various ideas.

During Generate Ideas it’s crucial to start with the right question (if you are a Liberating Structures fan, think of Structuring Invitation). A well-formulated question will elicit relevant and thoughtful ideas. An unclear question will only confuse the participants. Express clearly what outcome you expect from the group. Be creative and inspiring. Help the group engage with their answers and bring their focus to the agreement that is the goal of the session. Here’s a couple of examples of good questions:

• For a Definition of Done workshop: “What characteristics should a backlog item have so that when you look at it you can honestly say that it is ‘done’?”
• For a team ground rules session: “What are the most basic, fundamental agreements you as a team need to stay productive and keep healthy climate?”
• For a team quality standards discussion: “What are the coding standards that are the absolute necessity to keep your source code at a quality level that you will be proud of?”

Stage 3. Group and Prioritize

Recommended techniques: grouping; dot-voting.

By this point, the group has generated a lot of ideas. Make sure each participant understands them well. Ask the participants to read their ideas aloud and encourage the group to ask clarifying questions. The most obvious ideas can be skipped. Don’t be afraid to ask questions yourself if you suspect something may not be clear to the group. During this process cluster similar ideas together. It is important for the next step when the group will prioritize their suggestions.

Because the session is timeboxed, not all ideas will get their share of attention. As a facilitator, you want the group to take away from the meeting what’s valuable for them so make sure that the most important ideas are discussed first. Ask the group to prioritize.

A popular way to facilitate this is dot-voting but the group needs to know what they are voting for. Just like in Generate Ideas, the right question makes a huge difference. I like to ask: “What are the most important ideas that absolutely need to be discussed today otherwise it will harm the team tomorrow?” Then, give each participant three dots and ask to distribute across any number of stickies they want. If the list of ideas is extremely large, increase the number of dots to five. They can place all the dots on the same sticky note or spread across any number of stickies in any proportion. [5] Clusters of stickies are counted as one idea in the voting process.

Once the group has finished voting, sort the stickies by the number of dots. Discuss the sorted idea starting from the ones with the most dots.

Stage 4. Discuss and Agree

Recommended techniques: open discussion; Decider, Roman voting, or Fist of Five.

The idea behind this stage is simple, but the execution is hard. Each idea needs to be discussed by the group. It is here when they inevitably enter the Groan Zone [6]. The conversation might and probably will get emotional, opinions will clash. If the discussions on a certain topic take too much time, split it into smaller items. Also, expect the group to come up with completely new ideas. In both cases, check with them whether they want to discuss new items immediately or put them at the end of the list. Don’t be surprised if the group wants to drop some ideas altogether. In this case, follow their agenda.

After an idea has been discussed, the group needs to agree whether they want to have it in the resulting list or not. My favorite way to do this is Decider from Core Protocols. Decider is aimed at a consensus by design (a decision is passed only if the entire group supports it and nobody objects [7]).

Build Healthier Teams with Core Protocols

Other options are Roman voting or Fist of Five. In both cases, you can decide to go for consensus or let the absolute majority win. Resist the temptation to decide trough open discussion. Although sometimes valuable, here it puts you at the risk of dragging out discussion and never reaching the outcome.

Stage 5. Close the Workshop

Start closing the session some 10 minutes before it ends. Recap the outcomes — which ideas have been accepted by the group.

Here are a few points that may be discussed during the closing stage:

• Decide what you want to do with the remaining items. The group might be happy to abandon them, especially if the ones that nobody voted for during the prioritization phase. It is likely they are not important enough and are safe to be dropped.
• If the group decides to continue discussing the remaining items, agree when a follow-up session will occur.
• Capture where you will document the outcomes. A good idea is to place the resulting agreement on an information (visual) radiator. An alternative could be a wiki page although it’s not preferred. Wiki is not as accessible or visual as a poster on a wall.
• Sometimes during the Discuss and Agree stage, participants come up with action items. Make sure those are captured too and somebody volunteers to take care of them. If there are volunteers, don’t sweat it. Likely, they are not important enough and are safe to be dropped.

Follow-up

Once the session is over, gather all the notes and documents the group has created and email them. If necessary, help the group create the visual radiators and register the action items.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

References

[1] Agile Manifesto (2001). Principles behind the Agile Manifesto. Available at: https://agilemanifesto.org/principles.html. Accessed on: May 19, 2020.

[2] Kaner, S. (2007). Facilitator’s Guide to Participatory Decision-Making, 2nd Edition. San-Francisco, California: Jossey-Bass Business & Management, p. 20.

[3] Derby, E. and Larsen, D. (2012). Agile Retrospectives: Making Good Teams Great. Dallas, Texas: The Pragmatic Bookshelf, p. 4.

[4] Kaner, S. (2007). Facilitator’s Guide to Participatory Decision-Making, 2nd Edition. San-Francisco, California: Jossey-Bass Business & Management, p. 48.

[5] Wikipedia (2017). Dot-voting. [online]. Available at: https://en.wikipedia.org/wiki/Dot-voting#Process_specifics. Accessed on: May 19, 2020.

[6] Kaner, S. (2007). Facilitator’s Guide to Participatory Decision-Making, 2nd Edition. San-Francisco, California: Jossey-Bass Business & Management, p. 18.

[7] The McCarthy Show (n.d.). Online. The Core Protocols v. 3.0.2. [online] Available at: http://www.mccarthyshow.com/?page_id=100. Access on: May 19, 2020.

Agreement Builder — Most Typical Agile Workshop Ever was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

Strategies for Handling Unplanned Work During Sprint

The question about what to do during a sprint when a team starts getting more and more unplanned work is still one of the most asked by the participants of my trainings and the teams that I coach. That’s why I created this poster based on the original article’s content.

It provides a concise overview of all eight strategies in a form that’s convenient to use during trainings and workshops. Feel free to download it, print, and share. Also, I’d love to know if you find it helpful and if you have any ideas how it can be improved.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

Unplanned Work Cheat Sheet was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

Communication is one of the biggest factors in a team’s productivity. Turns out it has a much bigger impact on a team’s success than individual performance of its team members [1]. In 2013 I was lucky enough to be in a workshop with Jim McCarthy where I learned about Core Protocols and how they can take a team’s communication to the next level. Since then I couldn’t stop being amazed by how powerful a tool it is. However, it took me a few years of practice to fully understand the potential it brings and here’s why.

What are Core Protocols in essence?

Let’s start with the definitions. What is a protocol, after all? Collins Online Dictionary, for example, gives several meanings:

If you read between the lines, you can deduct some common logic behind all four. First, there are two or more sides participating in an exchange. Second, there’s a set of rules. Then, there are some typical situations when the exchange happens. Finally, the sides agree to use the rules, while making an exchange, all during those typical situations. And that’s exactly what Core Protocols are. It’s a set of rules a team uses in their daily communication to make it easier and clearer. In practice, it takes the form of marker phrases. Whenever somebody says a marker phrase — a protocol is initiated and all the team members are expected to respond in a very specific way.

Here’s an example. Say, you want to ask for feedback. The usual problem with asking for feedback is, the feedback they give you back is oftentimes plain useless. And it’s not intentional — the other person just doesn’t know what you expect from them. However, there’s an easy way to improve this. Use Perfection Game, one of the Core Protocols. How does it work? You set it up by saying “Would you perfect this thing for me?” — and tell exactly what to perfect — “My presentation today. Can you rate it on the scale of 1 to 10?”. The other person gets a clear marker that you’ve started a Perfection Game. They already know how to follow up: they rate your presentation on a scale of 1 to 10 and tell you what they liked about it. They also add a couple of suggestion about what you need to do in order to make it a 10. You’ve just saved a lot of time and received some valuable — and actionable — tips.

Are Core Protocols just another facilitation technique?

Some of the Protocols have gained specific popularity in the Agile community. Perfection Game seems to be everybody’s favorite and pops up in blogs and articles quite often. Some others receive occasional attention too. But Core Protocols are rarely discussed as a whole.

Indeed, many of them can be used as mere facilitation techniques — and it’s a good starting point for an inexperienced or skeptical team. However, there’s much more to Core Protocols than just this. Core Protocols have much more profound goals than simply helping run regular meetings. The expected effects include[2]:

1. Closer interpersonal connection.
2. More efficient collective decision making and related accountability distribution.
3. Better team and personal alignment.
4. Achievement of a shared vision.

A team that applies Core Protocols systematically can expect to fundamentally change its way of communication and ultimately its culture.

In which way are Core Protocols powerful?

I like to think about Core Protocols as of a way to ‘preprogram’ people to react to common (possibly unpleasant) situations in a healthier way. What do I mean by that? A lot of the problems in communication occur because of our own perception. Emotions are caused not by the external events that are actually happening but rather by a person’s own beliefs, especially irrational beliefs [3]. With Core Protocols you can rewire the circuit by making a team agree on how they are supposed to react when push comes to shove.

A good example is the Check Out protocol. The idea behind it is simple. Any person may leave any activity if they feel that they can’t participate anymore. Reasons can be different: not adding value to the activity, tired and falling asleep, too emotionally charged to continue, and so on. Simply leaving the room would offend people because common belief is, it’s impolite. Especially so, if a person leaves in frustration. Check Out provides a graceful way out of this. It allows a team to agree: anyone has the right say “I check out” and walk out of the room. So, when this actually happens, everybody knows how to react and that they are not supposed to blame the person and or question their reasons. In exchange, the ‘quitter’ promises not to make a fuss out of it and commits to rejoining the team as soon as they can. In a sense, by agreeing to use Check Out team members replace the traditional belief (it’s impolite) with a new one (it’s expected, it’s how we communicate).

Another thing that makes Core Protocols so powerful is how they are designed. Each protocol is phrased very carefully. Every phrase tries to nudge towards constructive and concrete results. Let’s take Decider and Resolution for example. Together they form a simple voting mechanism. It starts with a person stating a proposal followed by an invitation to vote (“one-two-three”). The voters can choose from “Yes”, “No”, or “Support It” (there’s also an “Absolute No” which is essentially a veto but let’s leave it for now). The proposal passes if there are enough “Yes’s” and no “No’s”. If there are “No’s” but not too many, they can be resolved with Resolution. The proposer asks the group “What can I do to get you in?” Take a close look at the phrasing. It deliberately directs the possible response to suggesting an improvement or an alternative. It leaves no room for complaining or pointless rambling. Compare it to asking “Why didn’t you like my proposal?”

Seems that you need a lot of self-awareness. Isn’t it too hard to use?

As you can see, all these subtleties need to be carefully explained when a team starts using Core Protocols. If not understood properly, the protocols can be easily misused. They also require a lot of self-awareness and a lot of trust from team members. Which raises a valid question: what if a team is not ready yet? The answer to this is that Core Protocols can be scaled. Many of them are easier to comprehend and can be used quite mechanically while still bringing considerable value. The Decider and Resolution mentioned earlier are good examples. Below figure demonstrates which protocols are more demanding in terms of team’s maturity and which can be used even if a team is not at the needed level yet.

Looks too mechanical/too touchy-feely. What if my team doesn’t buy it?

Okay, but what if the team doesn’t buy the idea in the first place? I’ve heard a lot of times how Core Protocols make communication too mechanical. I’ve also seen people not being comfortable enough with how Core Protocols made them open up before their teammates. First of all, with the chart above you can tailor the protocols to the team’s level of readiness. But then, if you still expect a lot of pushback, just don’t tell them what it is. Start using the protocols yourself without explaining them. Let the team learn by doing. You may even change the wording slightly to make it sound more natural and less protocol-ish. For instance, you may start checking in to each meeting or running Deciders without telling. When you see that the team starts getting used to a protocol, explain and add another one. Hopefully, after a while, you will be able to introduce Core Protocols formally. But even if not, it shouldn’t be a problem because you can stay undercover like this indefinitely and still get a lot of value.

When and how is the best way to start?

Core Protocols are a part of my starter kit for new teams (more on that in future posts) and I think that it’s the best time best to introduce Core Protocols. The sooner they’ll start the sooner they’ll learn. Also, supposedly, it should help a team overcome the storming phase faster because they will have more open and constructive communication. However, nothing prevents you from starting with the protocols even in existing teams.

I like to introduce Core Protocols in a short session, usually 1.5 hours. I start by explaining what Core Protocols are and how the team will benefit from them. Next, I let the team read through Core Commitments — this is the foundation of Core Protocols, a list of statements somewhat similar to Agile Manifesto a team commits to follow. Once the commitment is formed, we quickly go over each protocol and I explain the mechanics. Many protocols can be confusing when you see them for the first time, so it’s crucial to provide examples. In the end, I run a Decider voting to get the agreement about using Core Protocols. If the team agrees, you are good to go. If the idea doesn’t get full support, together with the team I tailor the set of protocols as described above. And of course, it’s totally fine if the team rejects it altogether. It’s extremely important that Core Protocols are only used when there are motivation and acceptance.

The next few weeks I allow the team to learn by doing and make sure that they get enough coaching in the usage of the protocols. I like this format because in a work environment it’s oftentimes not so easy to carve out time for a full-size training. However, if you have the possibility to have a proper training, always go for a training.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

References

[1] Pentland, A. (2012). The New Science of Building Great Teams. [online] Harvard Business Review. Available at: https://hbr.org/2012/04/the-new-science-of-building-great-teams [Accessed 17 Jan. 2019].

[2] McCarthy, J. and McCarthy, M. (2002). Software for your head. Boston, Massachusetts: Addison-Wesley, xxiii.

[3] Sarracino, D., Dimaggio, G., Ibrahim, R., Popolo, R., Sassaroli, S., Ruggiero, G.M. (2017). When REBT Goes Difficult: Applying ABC-DEF to Personality Disorders. Journal of Rational-Emotive and Cognitive-Behavior Therapy, 35(3), p. 279.

Build Healthier Teams with Core Protocols was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my previous post, I tried to answer the question of what to do with the bugs found during an iteration. After that, a few people have asked whether estimating bugs is a good idea and if it is how to do it. Obviously, there are only two options and each of them has their pros and cons. Before drawing conclusions, let’s take a look at both. Note that here I assume we are talking about a team that works in sprints and does sprint plannings.

Not Estimating Bugs

• It helps to focus on the delivery of value. The logic here is that when a team calculates velocity they only count new feature development — the only part of the work that provides end-user value. Bugs are considered merely one of many factors that lower velocity. This (supposedly) helps the team to be more rigorous about not letting bugs escape because no one wants their velocity to drop to zero. The argument against this is that velocity is a poor metric for value. The only true thing it measures is the team’s capacity which does not necessarily translate to value.
• Long-term planning becomes more accurate. During long-term planning, you rarely estimate bugs because at the moment of planning bugs are yet unknown. If your velocity only includes new features and your forecast only includes new features, you can simply divide forecast by velocity to get your estimated date of completion. The counter-argument here is that new features are continuously added to the backlog at any moment in development, many of them after the long-term planning. Thus, they are as unknown as bugs and not estimating bugs doesn’t make it easier. Instead, tracking work items by type (e.g. planned, unplanned, bugs) will provide you with enough data to adjust any kind of long-term forecast.
• Bugs are hard or impossible to estimate. Oftentimes bugs are much harder to estimate. This is especially true for old bugs or bugs found in production because the team has already lost the context. Oftentimes the team itself hasn’t written the buggy code that they need to fix. One can answer to this that new stories might be just as vague and hard to estimate as old bugs. Fresh bugs, on the other hand, can be estimated relatively easily since the team still has the necessary context and there’re not so many dependencies in the code yet.

Estimating Bugs

• It’s much easier for a team to plan sprints. In the end, velocity is a capacity metric and its purpose is to help a team assess their own capacity for the next sprint. This task becomes much simpler if you include all kinds of work in the calculation.

To Estimate or Not to Estimate?

Generally, I find that teams feel much more comfortable with estimating bugs and the idea of only measuring “new stuff” doesn’t provide such a great psychological effect as it’s supposed to. I used to have a strong opinion about this in the past and insisted on not estimating bugs. Over time I’ve come to realize that what’s more important is keeping your estimation as transparent, clear, and consistent as possible. So, generally, I estimate bugs with my teams. In the end, forecasting is a manager/Agile Coach’s jobs and if it complicates things for you but makes it easier for the team — that should be your preferred course of action.

How to Estimate

Considering the thought that you need to be consistent with your estimations, the answer becomes pretty obvious. You want to estimate them in the same way you estimate everything else. That means if you estimate in story points using Planning Poker, you should do Planning Poker on bugs too. If you estimate with Magic Estimation (which I find more helpful), bugs should also be on your estimation board.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

Estimating Bugs — Yes or No? was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s another surprisingly popular topic that confuses a lot of people. What should you do when you find a bug during an iteration. Should you work on it immediately or should you put it off for later? Do you have to track it on your task board or is it not worth the time? The answer is actually not that complicated. Let’s take a look.

There are essentially only three ways to handle a newly discovered bug:

• fix it now,
• fix it later,
• ignore it.

Which strategy to choose depends almost exclusively on two things: the criticality of the bug and the expected time to fix. Let’s take a closer look at each of the strategies.

Read a related article about unplanned work during sprint:

Strategies for Handling Unplanned Work During Sprint

Fix It Now

What to do. Fix it immediately as a part of the current sprint.

When to apply. The strategy proves to be sensible in either of two cases: when the bug is quick to fix — and then it’s easier and cheaper to fix it immediately; or when it’s critical — and then you don’t really have another choice.

How to track. There’s a lot of questions specifically about how to track non-production bugs that have been found during active development of a user story. You can track it in many different ways and the easiest one is, of course, not to track it at all. It works best for small bugs that can be fixed within a short amount of time, typically, a couple of hours and allows you to avoid unnecessary bureaucracy.

That’s not always the best option, though. In the majority of cases you still want to visualize it because it’s blocking the user story and you want to see blockers on your board. There are a couple of options how you can do it.

On a physical board the typical approach is to put a red sticky note over the card in progress. It can be a bigger piece of paper with additional information on it or just a small red sticker. If you want the bug to be accounted for against your WIP limits (provided you have them) than you may want to put a separate card on the board in addition to the red sticker. It will occupy additional space on the board and will be counted towards the limit in the respective column thus incentivizing the team to fix the bug.

If your tracking tool is digital, your options depend a lot on the software you use. Let’s take Jira as an example. What I’ve found to work the best is having a special issue type called Sub-bug (the name doesn’t really matter here) which is just another version of a Sub-tasks. It’s also a good idea to flag the story for even more salient visualization — that’s the analogue of a red sticker on a physical board. Creating a first-class bug entity is still possible, of course, with the same premise as in the physical board example above.

Fix It Later

What to do. Create a new backlog item and put it in the product backlog. After that the bug is planned for future iterations just like any other backlog item.

When to apply. Sometimes, while still being critical, the bug might not be critical enough for you to fix it right away. Especially if it seems to be too large. This applies both to bugs found in production and to bugs that have been found during active development of a story.

How to track. Create a new card and put it in the backlog. If you have specific types of cards for bugs (usually you do), use them. On a physical board it’s typical to have red sticky notes for bugs, in tools like Jira by default there’s a specific entity type called Bug or Defect.

Ignore It

What to do. Do, well… nothing.

When to apply. In some rare occasions it’s not worth it to bother about the bug in the first place. This may happen when the bug seems to be relatively hard to fix while the impact of not fixing is minuscule. You accept the risk with the notion that if it’s really important, the bug will be reported again at some point.

How to track. You don’t track it. If you’ve already been working on the bug for a while and have a card for it, simply remove the card from the board.

Production and Non-production Bugs

At first glance, production and non-production bugs seem different. But if you think about it, the difference is not that huge. If the bug small or extremely critical, you’re better off fixing it on the spot regardless of when you’ve caught it. If it’s too big to fix it now, you put it on the backlog, again, regardless of the timing. In other cases you simply don’t spend time on it. The only difference is in how you decide how critical it is. In case of production bugs you will be leaning much more towards fixing it later because they tend to be bigger in size and require more work. For non-production bugs in the majority of cases it makes more sense to fix it now while the context is still fresh.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

Strategies for Dealing with Bugs During Sprint was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

Estimations is a hot topic in software development. There are articles written, talks given, and books published. When to estimate, how to estimate, and whether to estimate in the first place — all these are not easy questions but I’m going to let you explore them on your own. Let’s assume though, you’ve weighed all the pros and cons and decided to estimate in story points. Chance are, you are looking at Planning Poker. It is probably the most popular estimation technique in the Agile community. I had played numerous sessions with my teams before it gradually started falling out of my favor. And I had reasons for that. But before we get into detail about why you shouldn’t use Planning Poker, let’s take a look at why you actually might want to use it.

What I Like About Planning Poker

Planning Poker was created by James Grenning in 2002 and seems to be a simplified version of another popular estimation method — Wideband Deplhi (although Grenning himself claims he would have forgotten Wideband Delphi by that time [1]). There were two problems he was trying to solve. First, estimates were taking too much time. Second, existing techniques failed to involve the entire team [2]. Planning Poker wasn’t very successful in solving the first problem, as you will see later, but it did well in solving the second one.

Incentivizing Discussion

One of the key elements of Planning Poker is conversation. Participants are expected to discuss the items until a consensus is reached in the estimate. A session facilitator usually makes sure the discussions happen if the group members turn out to be too inert to do this on their own. Sometimes it leads to valuable discoveries.

Protecting From External Influence

It seems to be a side effect of Planning Poker but it’s exactly what Wideband Deplhi was aiming at. There is some scientific evidence demonstrating that in their estimates people tend to gravitate towards the number they’ve been exposed to before the estimation started. This happens even if the number is totally random or incongruous. This effect is a cognitive bias and is called anchoring [3]. So, whenever you involve more people in an estimation process, you don’t want them to know each other’s estimates lest they are not anchored. Another reason for anonymous estimation is that participants tend go along with the most authoritative opinion in the room. You want to avoid that too. Even simpler than that, people may be just too lazy to make up their own opinion. In any case, forcing each participants estimate on their own effectively removes the effect.

What I Don’t Like About Planning Poker

At the same time there are a lot of things that don’t work in Planning Poker as well as you would expect them to.

Faster, Still not Fast Enough

While Planning Poker seemingly has achieved some success in speeding up the estimation process, it could do much better in this field. During the Poker sessions a lot of time is still wasted on figuring out how exactly to play the game, especially in inexperienced groups. Turns out, the process is not entirely intuitive and people need to be thoroughly instructed before they fully understand the rules and the dynamics of the game. What’s worse, it doesn’t seem to improve a lot over time. After a team gets the hang of the rules numerous discussion keep popping up about how exactly the rules should be interpreted. Should we go for another round? Why don’t we just take the bigger number? No, you can’t just average out, we need to come to a consensus… And it goes on, and on, and on.

In defense of Planning Poker, Grenning in his original paper suggested not to spend too much time on trying to reach consensus. If you can’t reach it quickly, don’t sweat it. [4] So, with the right approach, the issue can and should be alleviated.

Not Truly Relative

But Planning Poker has a much more serious flaw: it actually makes it harder to use story points properly. In Planning Poker items are estimated one by one and a group is supposed to compare each item to a baseline item (typically a ‘1’). It’s exactly where lies the main problem. In their heads participants have to figure out how many times bigger the item is and it looks like human brain is pretty bad with this kind of operation. It tries to simplify the task by creating an image of each size on the scale and unconsciously translates it to time intervals (e.g. 2–3 days for size ‘2’). While the entire idea of relative estimations is to compare items against each other, people start comparing them to fixed time intervals. This is not much different from estimating in hours or days. After all, hours and days are fixed time intervals. Planning Poker, designed as a relative estimation technique, turns into absolute estimations without you noticing. Have you ever seen during a poker session somebody saying ‘it feels more like a 3 to me’? This is a dead giveaway the effect is taking place.

There‘s a way to get around this problem by triangulating with two or more values used as baselines [5]. It helps, but unlikely removes the problem entirely. There is another method that essentially does the same thing, but does it naturally and is faster and easier to understand.

Magic Estimation as a Fast and Effective Alternative

So, is there really a better alternative to Planning Poker? I believe there is. It’s a family of estimation techniques that share some common characteristics:

• they are visual;
• the estimation is done by moving cards around on a white board;
• the goal is to align the cards in groups left to right by size from small to large.

You may have heard about them under various names: Silent Grouping, Magic Estimation, Affinity Estimation, Swimlanes Sizing. I will call them Magic Estimation (indeed, it feels like magic the first time you experience it). The differences in these methods are minor and which one exactly to use is a matter of taste.

So, what Magic Estimation can offer that Planning Poker can’t?

Simple

The rules of the technique are extremely simple. You basically only need to draw the estimation board. Once people see the board, it takes a couple of minutes to explain the gist of the game.

Lightning Fast (With a Caveat)

In all versions of this technique communication is limited in some way to speed up the exercise. But even in fully unconstrained versions conversations are triggered mostly when there’s a disagreement between players. Procedural overhead is very little and no discussion occurs if it’s not needed.

Gains in speed come with a caveat, though. You can’t expect participant to estimate something they have no clue about, which means they still have to spend time discussing the items they estimate. It would be a lie to say that you can shrink a one-hour Planning Poker session down to 5 minutes, because in Planning Poker discussions are an integral part of the game and in Magic Estimation you need to hold these discussions beforehand as a part of preparation. However, there’s still much less overhead since the conversation format is not mandated. I’ve seen real teams doing two-hour sessions to discuss three months worth of work followed by a 5-minutes estimation exercise. Imagine estimating several dozen items using Planning Poker.

One may argue that while Magic Estimation saves you a lot of time, you might be losing in accuracy as opposed to Planning Poker. It’s a valid concern but here’s the paradox. Conventional wisdom has it that estimating large backlogs with Planning Poker is slow as hell and thus impractical, so nobody does this anyway. Surprisingly, estimating iteration backlogs with Planning Poker is no more practical. On the scale of two weeks the error margin is a few of user stories at the very worst. When so little is at stake, there’s no rational reason for perfect estimation accuracy. Instead, it’s better to turn your focus and energy to breaking work down into smaller shippable pieces and making the team deliver truly working software at the end of each sprint — that is, actively learning and reducing risks.

Prepackaged with Relative Sizing

The part that I love about Magic Estimation the most is its visual nature. It makes it almost impossible to avoid estimating relative. You are literally forced to compare items against each other by having to place them on the board either left or right. That’s the best way I’ve found so far to quickly make people understand relative estimations.

There’s a a reason why I think it works. It’s typical to use the (slightly modified) Fibonacci sequence in relative sizing. Human brain is much better suited to comparing on a logarithmic scale [6] and the Fibonacci sequence is an exponential function that makes one (strictly speaking, it becomes one if interpolated to a continuous function) [7][8]. Magic Estimation is in fact a heuristic that leverages this fact. The idea is simple. If one can spot a difference in size between two adjacent items, it is likely that those items are approximately in relation to each other as the corresponding Fibonacci sequence numbers. Because if they weren’t, the difference wouldn’t be noticed and the items would end up being the same size.

Conclusion

Planning Poker is a technique that still has its use and is preferred by many. In my own practice I found something else that provides me with more value and it is Magic Estimation. Here’s a quick comparison between the two.

What Planning Poker is good at:

• facilitating deeper discussion and risk identification.

Where Magic Estimation trumps Planning Poker:

• saving time,
• producing good enough estimates at much lower cost,
• promoting the right understanding of relative sizing.

The only time when I prefer Planning Poker over Magic Estimation is in immature teams that have a hard time starting a conversation. Planning Poker forces people to speak, so if you think they have a hard time starting a discussion, it may be a viable option for you.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

References

[1] Grenning, J. (2002). Planning Poker — The Original Paper. Retrieved from https://wingman-sw.com/articles/planning-poker

[2] Grenning, J. (2002). Planning Poker or How to avoid analysis paralysis while release planning. Retrieved from https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf, p. 1.

[3] Thaler, R. and Sunstein, C. (2009). Nudge: Improving Decisions About Health, Wealth, and Happiness, Kindle Edition. New York, New York: Penguin Publishing Group, p. 23.

[4] Grenning, J. (2002). Planning Poker or How to avoid analysis paralysis while release planning. Retrieved from https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf, p. 1.

[5] Cohn, M. (2016). The Best Way to Establish a Baseline When Playing Planning Poker. Retrieved from https://www.mountaingoatsoftware.com/blog/the-best-way-to-establish-a-baseline-when-playing-planning-poker

[6] Vsauce (2018). 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35… Retrieved from https://www.youtube.com/watch?v=Pxb5lSPLy9c

[7] If the Fibonacci sequence is plotted as a curve — is it an exponential curve? (2017). Retrieved from https://www.freemathhelp.com/forum/threads/107174-If-the-Fibonacci-sequence-is-plotted-as-a-curve-is-it-an-exponential-curve. Accessed on: August 9, 2018.

[8] Fibonacci number. Retrieved from https://en.wikipedia.org/wiki/Fibonacci_number#Relation_to_the_golden_ratio. Accessed on: August 9, 2018.

Why I Stopped Using Planning Poker was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are two mistakes in understanding the concept of sprint (or Agile iteration) that I see quite often. Wherever they appear, these two mistakes completely negate the benefits that the sprint brings. They reduce transparency and predictability of delivery and add unnecessary procedural overhead. Those two common mistakes are:

1. Making a sprint longer. This mistake is typical in situations when a team is falling behind the schedule but still wants to complete the entire planned scope before declaring the end of a sprint.
2. Cloning (digital) cards or tickets from one sprint to another. This happens whenever a teams has incomplete work items at the end of a sprint but clones them into subsequent sprints instead of carrying over. The original items get closed as if they were done.

Over the years I’ve employed a mental model that helps me combat these mistakes and I’d like to share it with you.

The concept of a timebox can be traced back as far as to the late 80's. As it had been adopted by Extreme Programming (under the name of ‘iteration’) and Scrum (as ‘sprint’) it gained even more popularity and has become the essential part of applied Agile [1]. The power of this practice lies in the idea that instead of fixating on scope a team must focus on delivering as much value within a limited amount of time as possible. However, this essential meaning often gets overlooked. The very name of the concept — a timebox — hints at how you should treat it: as a time span and as a bucket (a ‘box’) at the same time. Let’s explore how these two aspects get misinterpreted and what thinking tool can help you to avoid misinterpretation.

Mistake: Making Sprint Longer to Accommodate to Scope

A team has planned 10 user stories for a two weeks sprint. On the last day, 9 of 10 are done, and the team is pretty certain the remaining user story should take about 2 days to complete. The team insists on extending the sprint. They eventually finish the story in 4 days, which results in the actual sprint duration of 14 days. The same keeps happening in the following sprints too.

Schedule slippages are quite a usual thing in software development. To a point that they may be considered inherent and unavoidable. When a slippage occurs, people have the intuitive desire to extend the sprint in order to deliver the full planned scope. A team — or team’s management, or the product owner — think that completing full scope is what defines the end of an iteration.

This mistake has its roots in traditional management that revolves around scope commitments as the primary tool for execution control. As soon as the scope for a project is defined and estimated, the commitment to delivering the scope is formed. The key focus now is fulfilling the commitment, i.e. delivering the scope before the estimated deadline, and if it’s not possible then the easiest way to fix this is to adjust the schedule. I’m oversimplifying here, of course, as there are still options for de-scoping and playing with the team size. Nonetheless, in this paradigm completing full scope is considered the baseline to adjust from. And that’s exactly what the concept of sprint (aka iteration or timebox) tries to turn upside down. This fact is aptly illustrated in the well-know diagram:

The adverse effects of changing iteration length at will are quite dramatic.

First, the whole process turns into chaos and sways the team off pace. The activities that are supposed to be regular and automatic now require case-by-case scheduling. This creates unnecessary procedural overhead. The team quickly gets tired of this and slips into ad-hoc process and ad-hoc in reality means no process at all.

Second, any kind of planning based on historical data becomes over-complicated and unreliable. One of the most popular metrics to generate historical data in Agile teams is velocity. Just like in physics it is a measure of distance covered in a unit of time, in software development it is the amount of work completed in a unit of time (the definition of ‘amount of work’ may vary from team to team). Now imagine your unit of time is variable. The very definition of velocity doesn’t make sense any more.

Think Instead: Sprint is a Unit of Time

Let’s take an astronomical hour as an example. You can’t change the duration of an hour —an hour is an hour by definition. Sprint should be regarded in the same way. Consider this analogy from your everyday life: if you need to mow a lawn but have only managed to do half of it in an hour, that’s your result, no more and no less. You may still keep on mowing but all additional work will be happening during the next hour. You don’t extend the hour. What you do instead is you adjust your plans and priorities for the next hour and think of what were the reasons that you hadn’t nailed it in your first attempt. You also get the understanding of your velocity: 0.5 lawns/hour. That’s exactly what a sprint is. It is the unit of time, not the amount of work you plan for it.

Mistake: Cloning Incomplete Work Items Instead of Carrying Them Over

A team has completed a sprint but “User Story X” is still not finished. The team wants to visualize the progress they’ve made on this story. On their task board they have a card for it. They rename it to “User Story X Part 1” and move it to Done. They also create a card named “User Story X Part 2” and put it in the next sprint. They don’t manage to finish the story in the next sprint either. So they create “User Story X Part 3” and now move “Part 2” to Done. This exercise repeats itself a few more times.

This one I’ve seen quite a lot, usually with digital task trackers (the much-hated Jira being one of them, which is quite surprising because Jira natively supports the “correct” way of carrying items over) — probably because the operation of copying is so cheap there. Whenever a team is not able to complete a story, they clone it to the next iteration. The original story becomes “part N” and gets closed and the clone is now “part N+1”.

There’s a number of possible reasons why this happens. The most obvious is probably the team’s desire to reward themselves for performing work, otherwise they are left with the feeling of unfairness. Another typical reason is cargo-culting the golden rule of fitting a user story in a single sprint. I’ve seen both in my career. Instead of focusing on the root cause, a team simply makes up an artificial completed item.

Such way of tracking work has numerous issues.

First of all, it never actually shows real progress. Whether a user story is done or not can only be evaluated with the ultimate objective criterion — is it live or not. In Scrum you can strengthen (or weaken) this criterion by the means of Definition of Done. This aligns with one of the Agile principles: working software is the primary measure of progress [3]. By cutting a user story into parts like shown in the example you are doing something as nonsensical as saying, “I’ve mowed half of the lawn, although I still don’t know how big it is”. How do you know then it’s a half and not a quarter?

Second, such tracking removes the incentive of slicing user stories vertically into smaller pieces. There’s no pressure to have a story that you can truly complete in one sprint because you have a 100% guarantee to have a completed item at the end of each and every sprint.

Then, if you use a digital tool for tracking, it messes up with your data. There’s no easy way to calculate true lead time or true velocity when you keep adding entities for the same piece of work. The data on the items doesn’t show true numbers and if you want true numbers, you need to aggregate them from multiple different sources.

And lastly, continuously cloning items simply wastes your time on unnecessary activities. I’ve seen teams wasting the entire sprint review on just creating new clones in TFS for the next sprint.

Think Instead: Sprint is a Bucket

Instead, think of a sprint as of a bucket and work items as of stones. You can fit only so many stones in a bucket. Completing a work item means removing a stone from the bucket. At the end of a sprint you just pour off all the stones from the old bucket to a new bucket. The same happens to the work items: they just get carried over to the next sprint’s backlog without change (and without re-estimation, as you may have guessed [4]).

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

References

[1] Agile Alliance. (n.d.). Timebox. [online] Available at: https://www.agilealliance.org/glossary/timebox/.

[2] Agile Business Consortium. (2014). The DSDM Agile Project Framework (2014 Onwards). Phylosophy and Fundamentals. [online] Available at: https://www.agilebusiness.org/content/philosophy-and-fundamentals.

[3] Agile Manifesto. (2001). Principles behind the Agile Manifesto. [online] Available at: http://agilemanifesto.org/principles.html.

[4] Cohn, M. (2007). To Re-estimate or not; that is the question. [online] Mountain Goat Software. Available at: https://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is-the-question.

Two Common Mistakes In Understanding Sprint was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you ever worked in a distributed team as a manager or a Scrum Master, you know that facilitating meetings online is painful. I know what I’m talking about because I worked in distributed teams for the most part of my career. So, I was constantly trying to find ways to make online facilitation as effective as it is in a room with participants being physically present. Over time I’ve learned that it will always stay subpar to a physical session. However, I’ve also found out that there are some very practical ways to narrow the gap between the two so that it becomes insignificant. In this article I will cover the key aspects of online facilitation:

• the principles I formulated based on a few years of experience;
• the tools that I prefer personally and the rationale behind choosing them.

I will also share the toolkit I’ve developed to help me with online facilitation in my daily work.

Note: the approach described below has proven to work for me in small groups. When a group gets bigger than 8–9 people, dynamics and the facilitation style change, which may require different tooling and different methods.

Key Points

In my experience, online facilitation can be almost as effective as the regular, “physical” facilitation. This becomes possible if you apply the principles and use the right tooling that gives you enough freedom and flexibility. The principles and the list of tools are summarized below. Further in this article I examine each of them in detail.

Principles of Online Facilitation

Foundational principle:

Keep it as close to physical experience as possible.

Supportive principles:

1. Use a webcam.
2. Everyone joins remotely.
3. Discuss in pairs.
4. Use a virtual whiteboard.

Tools of Choice

1. Zoom — a powerful online conferencing tool.
2. Google Drawings — a drawing tool that can be used as a virtual whiteboard.
3. Kiryl’s Facilitation Toolkit — a collection of canvases for Google Drawings. The Toolkit is free and regularly updated.

The Problem

The ideal process of facilitation, as defined by Sam Kaner in his book “Facilitator’s Guide to Participatory Decision-Making” [1], looks like this:

In the middle of a facilitated session sits the most important part — the Groan Zone. It’s called this way because this is where all the tough and unpleasant discussions happen. However, this is also where the brightest and most creative ideas are born. The facilitator’s task is thus to help the group approach Groan Zone gracefully and, while the group is pacing through the zone, provide enough support so that they reach the final decision constructively and with mutual respect. Since this part of the session is extremely uncomfortable and requires a lot of focus and determination, a group will most certainly try to avoid it. There are numerous ways to do this, but in my experience the absolute majority of online meetings falls into either of the two scenarios, both caused by the fact participants can’t see each other.

The first one is what I call Awkward Silence.

A facilitator asks a question, but nobody responds. The facilitator asks again, but the silence still remains, oftentimes even after addressing people directly. An open question posed to the entire group is almost a guaranteed way to plunge into Awkward Silence. What happens afterward is typical: the feeling of uneasiness that rises in the facilitator transforms into the urge to reanimate the conversation. The facilitator quickly falls back to talking themselves, which only exacerbates the problem: now, as the facilitator is talking, participants feel even less incentivized to join the discussion. No discussion occurs in the end and the group feels their time is wasted.

The second scenario is The Broadcaster.

This situation is quite typical to offline meetings, but it is much more common and much harder to deal with in an online setup. What makes it especially difficult, is the fact that the facilitator can’t use non-verbal means to intervene: look into a person’s eyes, walk around the room, tap them by their shoulder. As a result, it seems nearly impossible to find the right moment to interrupt the Broadcaster’s energetic monologue without shouting over them. And shouting is hardly an effective way to continue a discussion.

Luckily, both scenarios can be easily avoided by designing and conducting a session in a way, that the level of participation is the same for everybody, non-verbal communication is not lost entirely, and the facilitator has the means to control the flow of the discussion almost as if it were held in a physical room. This is where the principles and the tools come into play.

Principles of Online Facilitation

As defined by Sam Kaner [2], the participatory values are:

1. Full participation.
2. Mutual understanding.
3. Inclusive solutions.
4. Shared responsibility.

Simply put, as a facilitator you want to make sure that the group speaks, listens, and reaches a decision in the end. The only question is, how to make this happen. Easier said than done when you are in an online conference. As first demonstrated by Alistair Cockburn and then restated by Scott Ambler [3], a face-to-face conversation is believed to be the most effective way of communication between people. I combined this idea with the participatory values and several years of my own experience. The result is the principles of online facilitation that can make online sessions almost as dynamic and productive as physical meetings. These principles are:

Foundational principle:

Keep it as close to physical experience as possible.

Supportive principles:

1. Use a webcam.
2. Everyone joins remotely.
3. Discuss in pairs.
4. Use a virtual whiteboard.

Let’s take a closer look at each.

Use a Webcam

One of the biggest downsides of online facilitation is that non-verbal communication is limited. A webcam helps you alleviate this setback.

With a webcam, participants can bring back non-verbal interactions at least partly. This makes the conversation more lively and the participants tend to stay more engaged. A webcam also has some practical advantages for a facilitator: you can see their mood and reactions. Are they bored? Are they excited? Agitated? It gives the facilitator valuable information about the state of the group and whether an intervention is necessary. Intervening also becomes much easier: you can do something as simple as waving at the webcam. People will react to the movement on their screens.

Everyone Joins Remotely

If a group is highly dispersed, this principle looks pretty self-evident. But is there a benefit for the groups, in which just a small part participates remotely. The statement seems to contradict the foundational principle: keep it as close to physical experience as possible. However, let’s take a look at it from a different angle.

If you’ve ever been in an online call as the only person joining remotely, you probably should be familiar with this situation. You call in. Everybody else has already gathered around a speakerphone somewhere in a room. They start speaking. The sound comes in muffled so you barely understand a thing. You almost fall asleep. Then, thirty minutes into the meeting there’s a sudden burst of laughter. It’s so loud your ears almost explode. Then the group gets back to mumbling for another thirty minutes and the meeting ends. You are left in confusion, frustration, and absolutely no desire to repeat the experience.

My observations show that having a minority joining remotely effectively removes them from the discussion. The major part — the people in a room — are at such an advantage communication-wise, they hardly notice they only speak to each other. So, when you are facilitating online, you have to make this trade-off: on the one hand you need to support full participation, on the other hand you want to keep high levels of energy. The participatory values come first here. Making everyone join remotely puts everyone on the same ground. Nobody gets the unfair advantage of a richer communication channel and nobody gets swept out of the discussion. Surprisingly, from my observations, this ends up in group dynamics much closer to a physical meeting than one would expect.

Discuss in Pairs

This technique also comes from offline facilitation, but I’ve found it to be most crucial to offline meetings. There are different approaches to information gathering during a session. One of the ways is individual writing. It is fast and prevents authoritative participants from influencing the group. On the other hand, it removes the benefits of exchanging ideas between the group members. The opposite is open discussion. Open discussions allow for free flow of idea and maximum conversation tempo, but are much harder to facilitate and much more time-demanding, especially online. Breaking up into pairs hits the sweet spot between the two approaches. On top of that, it makes it much easier to prevent situations like Awkward Silence or The Broadcaster because it is much harder to keep silent or hijack a conversation when there’s only two people participating.

As a rule of thumb, I try to break people up into pairs in such a way that:

• people with different skills have a chance to talk to each to bring different perspectives into a topic;
• if there are multiple break-ups during a session, people exchange pairs, so that, again, they can bring more perspectives into the discussion;
• people in the same location may have discussions in pairs at their desks and return back to the rest of the group when necessary — this saves time.

Use a Virtual Whiteboard

Although not much can be said about this supportive principles, I find it, perhaps, the most important of all. A whiteboard (or a flip chart) is an powerful facilitation tool. Many facilitation techniques either are built around a graphical metaphor or imply lots of writing on a board or on sticky notes that are then placed on a board. A common mistake many beginner online facilitators do is using a text tool, usually a forum or a wiki page. The issue with this approach is that once the text has been written, it’s very hard to manipulate it: you can’t easily move or group ideas and voting for pieces of text might become problematic. Another downside is the lack of the graphical component. The group is missing out on the advantages of graphical metaphors. Last, a text tool limits the opportunities for the group to interact with their own ideas, such as moving them around a board, putting emphasis visually, color-coding, and so on. In an online session every chance to make a group interact is precious. A virtual whiteboard gives you these small opportunities that help keep the energy levels high: creating virtual sticky notes, dragging them around a board, voting with dots [4] that are actually movable, and many others.

Choosing the Right Tools

I‘d like to share the list of tools that I personally prefer and would recommend for online facilitation.

Online Conferencing Tool

The principles of online facilitation give us very convenient criteria for choosing a conferencing tool. Since we are going to use a webcam and ask everyone to join remotely, the tool should

• provide video calling (almost every tool on the market can do this today);
• allow group calls;
• be able to display multiple participants on the screen.

Since discussions will be held in pairs,

• the tool should support breaking up into sub-groups (and the feature should work smoothly);
• if it doesn’t support sub-groups, a viable workaround should be possible.

Based on these criteria my favorites are Zoom and Google Hangouts.

Zoom is a tool with a very pleasant user interface and a multitude of convenient additional features. The main advantages are:

• shows up to 6 participants on the screen in a thumbnail view;
• does this even when someone is sharing screen;
• has a break-up functionality out of the box that is very stable compared to the other tools I had experience with.

The free version includes everything you might need but limits the duration of a meeting to 40 minutes. After 40 minutes it drops the call and you need to start a new one.

Google Hangouts is a free video-conferencing tool with limited features, but it has almost everything that’s needed for online facilitation. The only thing from the list it can’t is breaking up into sub-groups. Here’s what it can:

• shows up to 10 participants on the screen in a thumbnail view (possibly, even more than this and definitely more than Zoom does);
• does this even when someone is sharing screen (except for the person sharing);
• multiple people can share screen at the same time;
• it’s free.

As for the break-ups, there’s a relatively simple workaround. It’s possible to have multiple browser tabs open with multiple different Google Hangouts conversations running at the same time. During a break-up section, ask everybody to mute themselves in the main conversation but keep it open. Then in each pair, one of the participant calls the other one in a separate browser tab. It takes not too much additional time compared to break-ups in Zoom.

Virtual Whiteboard

For me it started with the need to facilitate team retrospectives, so I tried several different applications that were made specifically for this purpose. Then, there were other more powerful tools that provide a wider set of features and act as full-fledged virtual wideboards. None of them was a good fit because of three reasons. Free tools were poorly implemented. The tools that were versatile and powerful enough were not free. Then, in both groups there were tools mostly designed with very specific meeting formats in mind, thus vastly limiting facilitation options. Eventually, I settled on Google Drawings.

Google Drawings is a general purpose drawing application. It wasn’t designed as a facilitation tool, so the UX sometimes is not perfectly smooth, but it has some key advantages:

• it has concurrent editing, just like any other Google’s office tool;
• it provides full freedom, as you start with a blank canvas and can draw on it virtually anything you want;
• it’s absolutely free.

Kiryl’s Facilitation Toolkit

As I started working with Google Drawings, I realized that my sessions can benefit from some prior preparation. That’s how Kiryl’s Facilitation Toolkit came about. Over time I built a collection of canvases that would help me with kick-starting any meeting. It began with different retrospective formats, but soon I realized that Google Drawings can be used for all kinds of facilitated sessions. The Toolkit is available for download on my website for free.

The Toolkit includes a number of retrospective formats, a blank canvas for retrospectives and a general purpose blank canvas, a few other types of meetings, plus a library of visual elements that cover many common facilitation tasks. The collection has been built gradually based on my own needs, so everything there has been trialed in practice and covers most of the Scrum Master’s needs.

The Toolkit will help you with:

• preparing retrospectives and other meetings — you can choose from one of the pre-designed templates and save a lot of time;
• designing own sessions — blank canvases and the library of visual elements provide great assistance here.

The most valuable option the Toolkit opened up for me, which was quite serendipitous, was the ability to quickly set up a session that hadn’t been planned. I’ve had quite a few occasions when I had to improvise and create sessions on the go. I would start with a blank canvas, then throw in a few common visual elements, such as sticky notes or dots for voting, lay them out in a particular way, add a few text hints, et voilà — you‘re all set to facilitate an unplanned meeting!

Examples of Sessions Facilitated Online

So, we’ve learned the principles of online facilitation and have a set of the right tools to facilitate online. Let’s take a look at how this plays out in practice.

Just like a physical facilitated session, an online meeting requires some preparation. Namely, a facilitator should bring with them some “stationery”, such as pens, sticky notes, or whatever else might be needed. In our case, it’s most likely colored boxes that act as virtual sticky notes, dots for voting, possibly, something else.

Usually, I place all auxiliary elements outside of the canvas. The working area remains uncluttered and the unnecessary stuff doesn’t appear on the final image when you save it after the meeting. The templates in Kiryl’s Facilitation Toolkit are already enhanced with the elements suitable for most of the cases you might encounter.

Below you can find some examples of the sessions facilitated with the help of Google Drawings and Kiryl’s Facilitation Toolkit.

Note: The examples are based on the sessions that took place in real life. They’ve been slightly modified for better readability and in order to remove all sensitive data. They are available in the Kiryl’s Facilitation Toolkit examples library.

Facilitating Sprint Retrospectives

Most sprint retrospectives look more or less the same, especially those that follow the five-stage framework by Diana Larsen and Esther Derby [6]. So, the templates for different retrospective formats have a lot of commonalities. A good example is the “Action Items & Agreements” area — the crux of a meaningful retrospective outcome.

The results of an online session look very similar to a physical whiteboard, perhaps even neater and easier too read. Moreover, as a software tool, Google Drawing invites for creativity otherwise not possible, as shown in the examples below.

Facilitating Other Types of Sessions

Of course, as I mentioned before, Google Drawings doesn’t lock you down to a specific meeting format. Below are a few more examples of facilitated sessions. Some of them had been thoroughly prepared, the others were improvised.

As you can see, online sessions can be almost as effective as the physical ones. And although in the Agile world we admit that face-to-face communication is king, sometimes it’s not up to you as a Scrum Master to decide whether the organization will stay distributed or not. And sometimes it may be economically reasonable or even dictated by the needs of the employees themselves if, for instance, they want to live in different countries. In the modern era of digitization this is not a problem anymore. As a Scrum Master, you should always have an answer to a challenge like this. Principles of online facilitation and the suggested tools are one such answer.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

References

[1] Kaner, S. (2014). Facilitator’s Guide to Participatory Decision-Making, 3rd Edition. San-Francisco, California: Jossey-Bass Business & Management, p. 20.

[2] Kaner, S. (2014). Facilitator’s Guide to Participatory Decision-Making, 3rd Edition. San-Francisco, California: Jossey-Bass Business & Management, p. 24.

[3] Ambler, S. (2014). Choose the Best Communication Technique Available. [online] The Disciplined Agile (DA) Framework. Available at: http://www.disciplinedagiledelivery.com/choose-the-best-communication-technique-available/.

[4] Wikipedia. (2017). Dot-voting. [online] Available at: https://en.wikipedia.org/wiki/Dot-voting.

[5] Appelo, J. (2014). Management 3.0 Workout, version 1.01. Rotterdam, The Netherlands: Happy Melly Express, p. 350.

[6] Derby, E. and Larsen, D. (2012). Agile Retrospectives: Making Good Teams Great. Dallas, Texas: The Pragmatic Bookshelf, p. 4.

[7] Kua, P. (2006). A Retrospective Timeline. [online] thekua.com@rest. Available at: https://www.thekua.com/rant/2006/03/a-retrospective-timeline/.

[8] Derby, E. and Larsen, D. (2012). Agile Retrospectives: Making Good Teams Great. Dallas, Texas: The Pragmatic Bookshelf, p. 81.

[9] Agile Alliance. (n.d.). What is Definition of Ready?. [online] Available at: https://www.agilealliance.org/glossary/definition-of-ready.

[10] Kniberg, H. (2014). Squad Health Check model — visualizing what to improve. [online] Spotify Labs. Available at: https://labs.spotify.com/2014/09/16/squad-health-check-model/.

Designing Online Meetings that Feel (Almost) Real was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

Classes of service is a mysterious concept in Kanban. The name itself might be confusing. Class of services? Classes of services? What does it mean, after all? Even more confusing is the practical application and, most importantly, why you would need them in the first place. While the implementation of сlasses of service is pretty straightforward, understanding the logical basis of the technique might be a bit trickier. As a matter of fact, in many occasions you won’t need them at all. We’ll explore this idea in the article, but before we do this, let’s start with a short story.

In a Bank

It begins in front of a bank office on the eve of a big public holiday when hordes of people roam the city trying to make their last preparations for the celebration. Unfortunately, on that very day I have to withdraw some cash from my business bank account.

I enter the bank. Although I know exactly what to expect, I’m still bewildered by the picture before my eyes. The bank is crammed. The lines are five times bigger than on an ordinary day. But I have no choice, so I go straight to my personal bank assistant to sign some papers. She redirects me to the bank teller where I will request the withdrawal. She asks me to get a ticket from the ticketing system — a simple kanban card. So far so good.

Then something strange happens. The next step is another teller that dispenses cash, but before redirecting me there, this teller takes my ticket from me. The ticket which reads ‘A’ and is the usual ticket for this kind of service. The teller gives me a new ticket instead. The new one has ‘B’ on it. Not really understanding what’s happening nor paying too much attention to it, I go back to the waiting line. The line is huge and intimidating. I brace myself and prepare to spend there at least an hour. The time starts ticking.

It is then when I notice, that there’s something specific about the waiting line. There’s a lot of people in the hall, all of them holding the ‘A’ tickets. Oddly enough, none of them has a ‘B’ ticket. None, except for me. I have my own queue in which I am the only person and my turn comes immediately. I haven’t waited even for a couple of minutes. Then it dawns on me. I’ve just experienced a privileged class of service.

Applying Classes of Service in a System

You might be asking yourself now, what exactly had happened in the bank? Let’s take a closer look.

First of all, a bank is a queueing system. Any queueing system has such characteristics, among others, as customer arrival rate and customer waiting time. The relation between these two parameters is defined by the very simple and equally powerful Little’s Law. What happens if the queues are large? Little’s Law has a definitive answer: waiting time grows proportionally. This is quite intuitive and this is what we observe in the story. The the main contributors to the situation are regular customers (the ‘A’-ticket type), but it affects everybody in the bank including the business clients (the ‘B’-ticket type).

However, from the bank’s perspective the situation is less than perfect. The bank doesn’t treat all its customers equally. Regular clients are sporadic. Their behavior depends much more on the bank’s location than on anything else. The loyalty of business clients, in contrast, is closely tied to the quality of service they receive. The bank doesn’t want precious business clients to suffer from poor service, even on public holidays. In order to mitigate the situation, they implement a very logical thing.

Usually the ticketing system in the bank directs all customers to a single queue. A customer takes a ticket with a number and waits until the number appears on the screen, then goes to whichever teller is free at this moment.

This time the bank does something different. It introduces two classes of service — the privileged Business class and the Regular class, which is everybody else. It allows to redirect all business customers to a dedicated queue served by dedicated tellers. The new dedicated queue is much shorter than the combined. And as we know from Little’s Law, it means decreased waiting time for all business customers. In other words, the business clients start receiving service of a privileged class. Another typical place where privileged classes of service are common is airports. There you can see Economy and Priority boarding lines and customers pay a premium to get into the latter.

In a bank, to make the privilege work, business customers are provided with excessive server capacity. Simply put, they are served by more tellers. Which means that regular customers will suffer from longer waiting times, but the bank is ready to tolerate that.

However, does a new class of service always bring significant benefits? Let’s examine this question in a few simple simulations.

Mechanics of Classes of Service

Mathematically speaking, we’ll be looking at the M/M/c queue model. In all our examples we will assume service rate, i.e. how many customers one teller serves per unit of time, to be

• service rate, customers per hour: μ = 15.

The simulation will run for 200 arbitrary customer somewhere in the middle of a typical work day. There’s nothing special about these numbers. All simulation parameters in this article are chosen in such a way as to provide better demonstration of various possible cases. If you want to play with the simulation yourself, the seed I used was 35, initial deletion ratio 0.7.

Let’s say, a bank starts with a single queue with no distinction between Business and Regular. For simplicity and to make it more illustrative, let’s assume:

• total arrival rate, customers per hour: λ = 70;
• number of tellers: c = 5.

As you can see, the expected (i.e. mathematically calculated) average waiting time (i.e. average queue time plus average service time) for a customer is 14 minutes. The observed waiting time is 9.3 minutes. This number will get closer to the expected value as we run the simulation for more customers. Now the bank wants to improve the service for its Business customers and creates a new privileged class of service. Two tellers are dedicated to serve solely the business clients. Let’s see what happens:

• let’s assume business customer arrival rate, customers per hour: λ = 10;
• number of tellers: c = 2.

Just by redirecting business customers to a separate queue the bank is able to improve expected waiting time almost threefold and observed waiting time almost twofold. Now, let’s take a look at what happens with the Regular customers:

• regular customer arrival rate, customers per hour: λ = 70 - 10 = 60;
• number of tellers: c = 5 - 2 = 3.

The queue grows to infinity, as does waiting time. Of course, in real life there’s no infinity. The bank either waits until the arrival rate drops and the system stabilizes or locks the door and denies service for any new customers. In both cases waiting time for the customers in the queue is huge and stays huge until either of the two events above happen.

An important conclusion we can draw from these three figures is that whenever there’s a privileged class of service that provides benefits to a certain type of customers, waiting time for everybody else increases. In other words, some people get their privilege at the expense of others.

But make no mistake. We’ve seen only one case from many possible. Let’s run the simulation with some different parameters.

For a system with a single queue:

• total arrival rate, customers per hour: λ = 50;
• number of tellers: c = 5.

The expected waiting time is 4.8 minutes, the observed waiting time is 6.2 minutes.

For business customers only (the parameters and consequently the results are the same as above):

• business customers arrival rate, customers per hour: λ = 10 (same as above);
• number of tellers: c = 2.

For regular customers only:

• regular customer arrival rate, customers per hour: λ = 50–10 = 40;
• number of tellers: c = 5–2 = 3.

The expected waiting time is 14 minutes, the observed waiting time is 13 minutes.

In this example the improvement for Business customers was insignificant, but it made the life of Regular customers much worse. Sometimes the game is just not worth the candle.

In software development the behavior of the queueing system might be a lot more complex. Practically it would be very hard to find the optimal conditions for having multiple classes of service. For instance, unlike tellers in a bank, it’s almost impossible to predict the change in service time if you change capacity allocation on different types of work. The only thing you can do is look back at the historical data and guess. That’s why the crucial part of Kanban is experimentation and empiricism. You and your team will have to make a decision whether you need a new class of service based on your own context and then put it to trial.

The Biggest Truth about Classes of Service

Finally, after thorough examination of all the examples, I can formulate the biggest truth about classes of services. I can summarize it in five points:

1. Classes of service intend to achieve a specific business goal. This is done by introducing a specific way of servicing customers.
2. Classes of services are differentiated either based on the type of customers or on the type of work that impacts the customers in a certain manner.
3. Introducing a privileged class of service for one type of customers or work always occurs at the expense of the other types of customers or work.
4. Adding a class of service is not always economically reasonable, as the unprivileged class may suffer unpropotional losses compared to the benefits that the privileged class gets.
5. Corollary to 1, 2, 3, and 4, when you think you need a new class of service, think again. The drawbacks may easily outweigh the benefits.

A good example is the Expedite class. By design, Expedite work items must be processed with top priority and can bypass the entire queue. This happens at the expense of all other types of work and makes other classes less predictable. The effect of this might be quite unexpected. Reduced predictability of regular classes of service sends an unequivocal message that the only way to get things done here is to expedite. This leads to abusing the practice and makes other classes of service even less predictable. The system enters a vicious cycle. That’s why teams usually have very strict rules of how many Expedite items can be in the system or how often they can be added.

And it has the same effect on less obvious kanban setups. Prioritizing bugs over features? Features will be delayed as long as there are bugs in the system. Putting deadline items in front of regular items? Your most valuable customers will be happy, but the combined frustration of everybody else may outweigh their voices. Sacrificing technical improvements for faster delivery? End users will get the desired features quicker, but innovation will suffer and the product’s internal quality will decay rapidly.

Conclusion

Classes of service is a powerful tool that can be used for achieving specific business goals. A privilege created by a class of service happens at the expense of other classes. Use classes of service when there’s the need to provide your customers or your business with specific benefits. This includes benefits with direct (features) or indirect (improvements) impact. Don’t use classes of service if there’s no business goal to drive them.But even when there is one, make sure if the new classes of service actually help rather then hurt.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

True Reason You Would — or Wouldn’t Need Classes of Service was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine a typical situation. Another sprint planning is coming close to an end. You have a sprint backlog for the next two weeks. Everybody is ready to leave the room and rush to development. That’s when someone asks out of the blue, ‘What about the sprint goal?’ Smile is gone from your face. This damn sprint goal! Not again! How do you expect me to think it up? I don’t have a slightest clue!

Did you ever find yourself in a situation like this one? Especially in the late stages of product development when the backlog mostly consists of gloss and shine stuff. I did and not once. Eventually, I’ve come up with a simple technique that helped me to overcome doubt and start creating decent sprint goals.

The Right Question to Ask

Usually, at the end of a sprint planning you already have a more or less prepared sprint backlog. Choosing stories for a sprint seems to be an easier task. Now take a look at your sprint backlog. What do you see there? Read through the sprint backlog items. Now ask yourself one simple question: ‘Why have you put exactly these items in the sprint backlog and not some other?’ Answer to this question is going to be your sprint goal.

Here’s how it works. Unless you’ve pulled the items from the product backlog in a completely randomized order (say, by throwing dice or choosing blindfolded) there’s been some rationale, some common theme behind your decisions. You just did this unconsciously, without realization. The sprint goal is already in your head and you already know it. The only thing remaining is too make yourself aware of it and bring it to light. You do this by contemplating the sprint backlog one more time and introspecting— through asking the question. Easy. Now confirm it with the rest of the team and you are good to go.

Let me give you a few examples to illustrate the idea. In your sprint backlog you have:

• Simplified horizontal search bar
• New bright attractive ‘Pricing’ button
• Narrower navigation panel.

Now ask yourself, why exactly these items? Turns out, you want to clean up your pages to make them look neater to end users. So, the goal might be ‘Improve UX of the main site functions’.

Another example:

• Refactor shopping cart
• Migrate to new payment service provider
• Pre-fill payment details

The items are a bit all over the place, but after a few minutes of thinking you are able to see a common theme pulling them together. A possible appropriate goal in this case could be ‘Remove blockers to further development of payment options’.

You may ask at this point, what if even after thorough inspection you can’t find a common theme? A sprint implies there’s a more or less tangible result in the end and a sprint goal helps a team stay focused on that result. In addition, it gives them a guideline for making own decisions. If you can’t state a goal, you deprive the team of focus and sense of direction and make the task much harder than it should be. So, if you can’t formulate a goal even after carefully looking at your sprint backlog, this is a hint to you that your sprint backlog is not good enough and you need a new one.

About the Author

Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer. If you want to learn more about Kiryl and the trainings he offers, check out his website and the schedule of the upcoming trainings. If you want to get the latest updates on Agile, Lean, and related topics, follow Kiryl on LinkedIn and Facebook.

Sure Way to Create Sprint Goals for The Doubtful was originally published in AgileLAB on Medium, where people are continuing the conversation by highlighting and responding to this story.