22 February 2016

Stand Up Estimation - How to estimate large number of user stories very quickly even with a big team?

Have you ever tried to estimate a large number of user stories with a big team? What was your best solution for that? Planning poker will be an awful experience, I can assure you of that. Everyone will become tired after a while; you won't get that many people participating after a while and the session will not serve its purpose. 

For a large number of user stories, what I'd like to do is to ask them to do "Stand Up Estimations". 

Preparation

You need to have a table and divide it into sections. Alternatively, you can use a wall with sticky notes or sticky user stories cards, up to you. You will need to define sections on your table. The sections present the size of user stories. The size can be in numbers (e.g. Fibonacci numbers) or simply words (e.g. small, medium and medium).


I divided the table into seven different sections, and in each section and both sides I have a number stuck (The numbers are based on Fibonacci sequence). I strongly suggest for you to remove the chairs out of the room if you can, or move it far away as possible.


You also need to print out the user story cards. If you are using Jira, you can use Agile Cards for JIRA. In the picture below you can see the amount of user stories printed and waiting to be estimated.


Let's Standing & Estimating begins!

On the entrance of the participants to the room, give them some of the user story cards. You want to make sure everyone get cards, so divide them in the fashion that everyone get a bunch of cards and no one feels to be left out.

Ask the participants to follow these rules:
  • The only thing that can be put on the table is the user story card. Nothing else can be put on the table, no laptops, cell phones, coffee mugs etc
  • Ask them to stand up while doing the estimation

First Round

Ask everyone to silently read the cards and estimate them to best of their knowledge. The estimation is the act of putting the card on the table. 

Second Round

This is when you ask everyone to look at the cards on the table. Ask the participants to read the user stories on the table and discuss the user stories. If there is a user story that they don't feel correctly estimated, they can have a discussion and change the estimate or keep it there.


Following Rounds

The discussion will go on. It depends on the complexity and the level of familiarity of the people with user stories. People get tired, then tend to use their energy for the most important user stories and the ones that they really think is important to discuss. Otherwise, when they are comfortable and after rounds of estimation, they sit out of the discussion; and literally on the chairs far away from estimation table. This will give you a good visual indication of how much more the session will take and when you need to puts and end to it. 


Final Round

You need to end the session somehow. It depends on your facilitation skills and how comfortable are you with the team. You can sense when there is not many important discussions are remaining. That's when you need to end the session. You can, alternatively, set a time limit for it. I would prefer the former approach. The former approach emphasize the value of estimation by estimating not all the stories.


To keep in mind

Some points you need to consider before facilitating this session:

  • This is a very fluid session, you need to have confidence in your facilitation skills to run it. You might get into situations that easily can get out of hand. Think different outcomes that might come out of it and be prepared for that.
  • I suggest running the idea of Marathon Sizing in team member's minds beforehand. You want them to expect them something new, especially for those participants that were used to a sit down boring long meetings.
If you are interested in estimation, you can read more @ http://blog.sheidaei.com/search/label/estimation

10 February 2016

How to use Check-In Protocol to incorporate feelings in a Retrospective

It was a very unhappy time when I had to run a retrospective for a team that their Scrum Master let go the day before. I had to show up and run the retro. It wasn't that easy to talk to people about what has happened and brought up the discussion. What I decided to do was to have a colorful retrospective and then get into the Core Protocols and use the Check-in protocol.



I have begun talking about how different men and women look at colors. It was more of an ice-breaker at this point. Then I introduced the concept of different feelings and the complexity of the language we use to describe our feelings. As an example for happy or depressed, one can find so many synonyms, which are different but similar. Building on top of that, I introduced the check-in protocol and why I am asking only to use the four feelings.

I liked the check-in protocol since it is easy to understand and it is forcing you to chose from the four feelings. It gives everyone a better understanding of how you feel and create a level playing field for introducing feelings into the discussion.

The results were amazing. If you just introduce the protocol by itself, it might be confusing. The fact that I have used the game to talk about different perspectives helped a lot.

The retrospective result was amazing too. Using check-in protocol helped the team to share their feelings which helped us with a huge wall of topics and feelings. The most important topic on the people's minds was their feeling about a team member and his departure. You can see how they described their feelings by using the biggest dot vote I've ever seen.