Agile Estimation - PlayScrum Delhi [25th July 2015]

What is Meetup

It is a social community of people who meet face to face to share their experience and learn from the experience of others. It is an informal way of interacting with people and learning from each others experience.

What is PlayScrum Delhi

It is group of Scrum/Agile enthusiasts within Delhi NCR who want to collaborate with others in the same region sharing the same interests. Details available here.

Who decides what we will discuss

The people who attend the meet-up collectively decide what area or topic we want to discuss. Agile Estimation was agreed to be the topic for the meet-up on 25th July 2015.

Agile Estimation - as it happened

Introduction

We started with a round table introduction of the people attending the workshop. It helps build an understanding of the breadth of the participants.

Estimation Game

To set the context of what was coming later on in the workshop and also to make sure everyone is involved, we started with an estimation game. People were grouped into small teams and then they were given some fruits and they had to come up with an estimate of how much effort will be required to eat that particular fruit.

The purpose of this game was to:

• prove that estimates are not scientific and they are limited to the local teams and not generic.
• the interpretation of '8' could be different for different teams.
• show why it is easy to use a benchmarked unit as against hours/time.
• to underline the fact that estimation is sizing the problem and not the solution.   

Why Estimation

We discussed why is estimation important and what are the different techniques that people are using to estimates. The purpose was to communicate that any of the approach could be used and there is nothing that scrum prescribes. The teams are free to use what ever technique that serves there purpose. Some common techniques were using Functional Points, Story Points etc.

Story Points

This is one of the ways of estimation used in agile projects. It has come from XP. It is an indicators of the Uncertainty, Complexity and the Amount of Work that requires to be done for a feature/story/task to be complete.

They help drive Cross Functional Behaviors within scrum teams as the size of the problem will remain the same from a DEV, QA, BA or any other perspective. It is also a relative measurement unit.

We took the analogy of building a room to explain the concept. To build a room you would need a 600 sq ft area, 3 windows, 2 doors etc. Now the size of problem to build this room will remain same. How it is built would defer. We concluded that estimation is for the WHAT and not HOW.

Story Point Matrix

This is a way of organizing your historically estimated data which can be used as a benchmark in the future estimations. Essentially this would a map of the possible story points with some example of stories against them.

Examples:

2 - preparing a cup of black tea

3 - preparing a cup of white tea

5 - preparing a glass of cold coffee.

Velocity

It is the amount of work that the team has been doing within a sprint. If you are estimating based on SP then the Velocity would be the No of SP delivered within the sprint. This is useful while planning your iteration as it helps you come up with a base number of SP that your team has historically delivered and hence helps you plan for future.

Exercise 

To clearly understand the concepts we discussed a problem. The problem was:

• There is a company with 3000 employees
• There are only 7 people in the IT support
• People are complaining that there IT related problems are not being solved and that is hampering their productivity.
• The problem gets escalated to the CEO
• The CEO calls a meeting and asks the team to come up with a solution to fix the problem within 24hrs. He emphasized that he needs a solution that goes live in 24 hrs and not a plan.

We then divided ourselves into groups and tried to solve the problem. The aim of this exercise was to prove the fact that the size of the problem was same for all the teams, the solutions were different. 

No Estimates

There could be different ways of estimating. People have started talking about not estimating at all. Some other ways of planning your iteration is to limit the number of stories in you sprint. This would mean that all the stories are relatively sized. The teams split the story if they feel it is growing bigger, this eliminates the need of a separate estimation session.

Conclusion

This is just interpretation of what we discussed during the workshop. I might have missed some points. If you feel there is a change that i should make, leave a comment about it and i will incorporate it.