Challenge, Estimate or Override (CEO) Game for Effective Estimations

You don't want to spend so much time with your team on estimating user stories, I totally understand that. However, the only way you know to do that is through planning poker.

True, planning poker is a great way of bringing up the conversation for user stories but it's not the most effective way to estimate those. I can assure you that if the originators of Planning Poker idea had more time spending on that, they wouldn't even introduce the concept. Or they will introduce it only as an introductory estimation activity.

What I am going to share with you is what I tried and I believe is really effective. I am calling it "Challenge, Estimate or Override" or for short the CEO game.

Using the CEO game you can reduce the amount of user story estimation activity in fourth or even less. Isn't that the point of being human and suck at estimations? To have less time spent on estimation and more on collaboration?

The rules are as followings:
  1. Printed out user stories as cards. I call them the pile. 
  2. Everyone stands next to one preferably long table. 
  3. The bottom of the table shows the stories that are estimated the smallest, and the top of the table the stories that are estimated the biggest.
  4. Each person on the team takes a turn to do one of the following
    1. Read a card from the pile and estimate it by placing it on the table. The lower the card is placed the smaller it is. (Estimate)
    2. Take one card that is already on the table and move it on the table. (Override)
    3. Take a card and challenge the person who put it on the table on their estimate (Challenge). It is then his/her (the person who is challenged) responsibility to argue on his/her estimate and then correct his/her estimate. 
  5. Team members take turn following the instructions above until there is no card to place on the table.
  6. When there is no card in the pile, team members get one last chance to play the game if they want. 
Note 1: The play can only use Challenge option once every two turns. This action is most useful when a player doesn't agree with the estimation and he/she doesn't know where exactly it belongs to.

Note 2: You want to ask your team members to stand for the whole exercise. Otherwise, they tend to lean and be passive on passing the pile. Think about it, who could have fun sitting down!

Note 3: At the end of this exercise you can assign Fibonacci numbers to the user stories if you need to. Fibonacci numbers begin with 1 and 2. The next number in the series would be the sum of the two previous numbers: 1,2,3,5,8,13,21,34,55 [3=2+1, 5=3+2, 8=5+3 and so on]

That's it! Now you have a list of user stories estimated in a fraction of the time you used to play poker. I suggest using a projector if you are using an electronic board, in case team members disagree on the terms of user stories and you want to refer to them. Then, any question regarding a user story can be clarified by discussing it in more details. 

The following pictures show the progress of estimation over the time (45 minutes) to get all the user stories (around 70).

Initial round
Next round
Final round - [I used Fibonacci numbers used to quantify complexity]

You can use this method to print out user stories as cards if you are using JIRA. 


A wonderful stop in the midst of my journey - Agile Coach Camp Canada 2015

Agile Coach Camp Canada has turned 6 this year. It was held at two location, in the east and west. With the east one, started one week earlier than the west. The ACCCA east was held in Cornwall Ontario. You can find more information about who attended the ACCCA this year on ACCCA website. The format of the conference was an open space format.

ACCCA15 at Nav Centre
To be filled with lots of agile people
You can see the marketplace for the first day. There were all kinds of games to be played at the unconference.

Lots of games!

Coaching leaders, management, executives and its challenges 

This conversation was initiated by Selena. You can see that it was discussed in depth the challenges of coaching leaders and how to overcome those challenges. Unfortunately, I wasn't present in person for the discussion.

Agile Management + Leadership

The fist talk that I participated was about the Integral and how it can help agile management and leaderships. It was given by Dr. Michael Hammon. To read more about Integral, you can visit Integral Theory & Thinking page.

Being brave & vulnerable

The next topic that I was really interested but didn't get the chance to attend was "Being brave & vulnerable". This talk was initiated by Gitte. For beginning on this, it is suggested to watch the ted talk from Brene Brown.

Patterns of Developing Internal Agile Coaches

Lyssa discussed the patterns of developing internal agile coaches. Why they are beneficial and if that makes sense to have internal agile coaches. You can see the notes below.

How to "install" Agile in an organization?

A really interesting talk was given by Mike and Declan on symptoms of installing Agile in an organization. The talk was mainly about their experience with a really brilliant client that he/she thought understood agile philosophy completely and asked Mike and Declan just to follow his requests and install agile in his/her organization.

Why do we measure?

Andrew begin a discussion on "Why do we measure / what measurements do we need to capture?" Unfortunately, I wasn't part of the conversation. However, it is a really valid point to consider and you need to ask why are you measuring and estimating? Is there a reason behind that? You might want to work on that!

Let's Draw a Toast!

Chris gave a presentation on how to draw a toast. I wasn't part of that either. The outcome of that discussion was really cool though.

Fail Safe Environments

A really cool topic that I participated was about Anzen or safety. You can find several good ideas from the posters to apply to your workplace. This topic was detailed by Isabelle and Caroline.

There were really cool posters on the wall too. I love the one that says: "Remember! Always follow the methodology".

Agile Testing Patterns

I also took part in the discussion for different testings and different perspectives to look them at. The four different aspect are Business Facing, Technology Facing, Support Development, Critique Product. You can run the same experience with your team and ask them to see where testing for their agile team sits on the board. Then you can bring the discussion that what else can be done. Also, a great thing to learn from this discussion is that as much as we move toward Critique Product, we can less automate the testing process. This discussion was led by Paul (more from him at Agile Testing Patterns session notesAgile Testing Automation).
Two important aspects we discussed include:
  • Some types of testing people mention aren't real types of testing.
  • e.g. Regression, Smoke/Sanity, Automation, and so on.
  • These are generally subsets of other types of tests, or describe a way of performing them (e.g. exploratory/manual).
  • We cannot, nor should we, automate *ALL* testing activities.
  • Some kinds of tests are too complex to try and automate (e.g. usability, UAT)
  • Some kinds of tests are enhanced with tools but cannot be completely automated (e.g. Security, Performance, Accessibility, Localisation, and so on..)

I found Learning Canvas on one of the walls of the conference. It is a really interesting idea to follow when you want to learn a new concept. You can simply journal what you have and where you are and where you need to get. It is like a pre-defined journey line for a specific topic.

And as always there were some talk that involved dancing. The talk was from Mike and Jesus on how they used their inner dancer to help their team become agile.

You can find a presentation I put together for my colleagues below.

You can find great articles regarding ACCCA through the following websites:


Quick intro to Scaling Agile with focus on SAFe

Several weeks ago I presented an introductory talk on how to scale agile in an organization, with the focus on SAFe and how the framework works. I am sharing the presentation here. I hope this will be a good intro for those interested in SAFe and how it works.

This presentation can be found on Google Slides.

You can learn more about scaling agile looking into other frameworks too. Some of them are as follows:


Agile is an art and Agile Coach is an artist, be an awesome one!

I was listening to an interview with a well known DJ years ago. The interviewer has asked the DJ what kind of music would he enjoy listening to. The DJ responded that he wouldn't enjoy listening to music anymore. He used to enjoy music before becoming a DJ. Now that he became a DJ, he had to listen to all kind of music and in many genres. He needed to do that to be able to energize the crowd that he was playing music for. He enjoyed the fact that people listening to the music are enjoying it. 

Agile coaches are like DJs. You are trying to bring joy in the team you are coaching. You are doing that by coaching them to be agile and live agile values. Achieving that, you need to know many different techniques and solutions. Not every technique will work for each team. Similar to a good DJ, you have to understand your crowd and find the right music for them, to play for them so that they enjoy it. If you find the right music (i.e. the right technique) for them, not only they will perform in a joyful manner (i.e. in an agile way) but also will enjoy themselves doing that. 
In a similar manner, we can compare chefs and agile coaches.
Please vote this lightning talk for Agile 2015 if you feel it is worth spending three minutes of your time listening to it.


How to engage tight-lipped team members? Or the unspoken secret of Speed Dating in Retrospectives!

In every team, there have always been one or two people that are tight-lipped. It is not easy to get them talking and participating in team discussions. You need to rely on your facilitation skills to get them involved in. The more experienced you are in understanding different personalities and dealing with them, the easier it gets to engage them in team activities.

However, if you just started working with a new team or you are yourself a novice Scrum Master (or a facilitator in general) it might be hard to engage tight-lipped team members; the solution: Speed Dating Retrospective style!

In the following section, I am sharing with you the steps to run a successful Speed Dating Retrospective. Use this as a template and customize it based on your team.

The Topic
  1. I asked everyone to come up with two topics, write them on sticky notes and keep it to themselves.
    • Note: There is no mention of speed dating yet. You can keep it secret until later on and surprise your team!
  2. After everyone was done with their topics, I asked one by one to come to the wall (or whiteboard) and stick the most important topic in their hand on the wall and discuss it. I asked team members if the topic is already on the wall (or something similar to it on the wall) to discard their topic and use the second one. 
    • Note: In rare cases that both topics are on the wall, ask your team members to come up with a third topic. Alternatively you can ask them to choose one of the two topics in spite of being a duplicate. It is up to you to decide based on the topics and the dynamic of the team at that moment.
The Discussion (Speed Dating)

Once everyone has their topic on the wall, it is time to describe the rules. The rules are easy and simple to comprehend (extremely simple if you know the rules of speed dating):
  1. Ask everyone on the team to find a partner; to group teams of two (in case you have an odd number of team members, one team will be three).
  2. Ask team members to discuss their topics with their partner, one on one, as if they are dating. You will give them 10 minutes time, and let them know midway to switch. In the first half of 10 minutes, the first person is talking about his/her topic and why he/she picked it up; second person is listening and giving feedback on the first person's topic. Then ask them to switch roles in the second half.
    • Note: It is up to you to decide how much time is needed for a dating discussion. You can change the 10-minute dating time based on the time you have and the discussions complexity. As a rule of thumb, you want to allocate 1 hour for each week in a sprint.
  3. After 10 minutes, ask team members to switch partners and find new ones. A new date, a new topic!
  4. The speed dating continues until everyone talked to every other person on the team.
You might ask what's the benefit of playing this game? Playing this game gives everyone a chance to talk to every other person in the team in person. People in the smaller group tend to be more relaxed and talk more freely, especially since there is a buzz going on in the room. No one is listening to them other than their partner. You would see them listening and more importantly talking actively. It will mesmerize you how this technique work, just give it a try.

Get them talking by asking them to talk to only one person at a time
Are you in an agile environment? Are you thinking of using this as one of your retrospective technique? If so, the next step after the speed dating round would be to ask your team members to choose two or three of the most important topics and focus on them. Since they have heard every other person and their topic, it will be much easier for them to pick the most important ones. You can use a dot-voting, vote by hands or sticky note voting technique, up to you. Afterwards, you would focus on the most important topics selected. As a team, you then would try to come up with ideas on how to tackle / incorporate them in the next sprint (or iteration). At this point, as a team you need to come up with action items for each topic. Also, make sure that team members volunteer to pick up action items identified. Again, note that how much more the tight-lipped team members are vocalizing. 

This was how I once ran a Speed Dating Retrospective
  • Intro – 5 Minutes
    • Why retrospective?
    • Three Words; everybody sums up the last sprint in 3 words
  • Proud & Sorry – 15 Minutes
    • What are team members proud or sorry about?
  • Group Discussion – 50 Minutes
    • Speed Dating (5 minutes and then switch partner)
    • Action Items; Dot Voting - Start, Stop, Continue
  • Feedback – 5 Minutes
    • Feedback Door


Scrum Master is Responsible for Game - The easiest way to communicate responsibilities of a Scrum Master

Have you ever tried to make sure that your team is completely aware of what the Scrum Master's role is about. Are you looking to educate your team members through playing a game on that? You are in the right place, once I played a game with my team to go over Scrum Master duties. There was good discussion going on and most of all we had fun playing the game.

What was the game you are asking? The game was me reading out statements and asking Team members to shout if they are True or False. I am calling it the "Scrum Master is Responsible for" game. After asking each question, if there was disagreement between team members regarding the answer, I would let them to discuss and challenge each other and at the end it was my duty to jump in and make sure everyone understood the topic correctly and the right answer for it.

Game: "Scrum Master is Responsible for v1.0"

These are the questions to consider for "Scrum Master is Responsible for?":
  • Scrum Master is responsible for successful delivery at the end of each Sprint.
    • Team is responsible
  • Scrum Master is responsible for preparing for the demo and presenting it.
    • Ideal demo is the one that stakeholders can do it themselves.
  • Scrum Master is responsible for removing impediments.
  • Scrum Master is responsible for facilitating the scrum events. The events include but not limited to the followings:
    • Daily Stand Up
    • Sprint Planning 
    • Sprint Review (Demo)
    • Backlog Grooming
    • Retrospectives
  • Scrum Master is responsible to assign tasks, user stories, spikes etc.
    • Scrum Master never assign tasks; it is the Team's responsibility.
  • Scrum Master is responsible for maintaining the documentations.
    • It is Team's responsibility on maintaining any documentation they are providing.
  • Scrum Master is responsible to maintain the Product Backlog.
    • It is Product Owners' responsibility to do so.
  • Scrum Master is responsible to come up with Definition of Done, Definition of Ready and team agreements and update them.
    • It is Team's responsibility to come up with those.
  • Scrum Master is responsible to coach Scrum team to follow Scrum / Agile best practices.
If you can think of any valuable question to this set please let me know.


Sorting Algorithms in Action

This is a nice visualization of the sorting algorithms and how they do with different sets of data.