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 to quantify complexity]

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

Update: It seems that JIRA has taken down the page linked line above. You can take a look at the Google cached version here (PDF version embedded below as well).

As an alternative solution, you can use Agile Cards for JIRA plugin and print out the user stories as cards.


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!


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.