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”.
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
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.
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.
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.
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