Estimation in Agile

What is estimation?

Agile is an empirical process. Agile projects teams breaks down software product / application (which we wish /aim to create) development into small chunks of work units which can be developed & deliver by agile teams to a customer at regular intervals. They are not expected to deliver the required end product in one go like we deliver in waterfall methodology. Team consistently focus on delivering smaller chunks of work on regular intervals & seek continuous feedback from customer to move towards the final software product / application which customer wants to build.

In our Agile way of working, the estimation is a crucial activity. In each sprint, the scrum team will go through an backlog estimation activity through either backlog refinement meeting or in sprint planning meeting. This will drive the shared understanding & collective commitment within team members on what can be completed in each sprint.

WHY

The real purpose is to have discussion between team members. So that they can build shared understanding about user stories / feature within the team. So everyone including Product Owner, Business Analyst and Development team are on same page and there is no different understanding.

So once the understanding is same among all of them then it becomes very easy to estimate and agree on.

When team should do estimation?

Ideally it differs from team to team based on their Agile maturity. However it is recommended that team should target to do story estimation in BACKLOG REFINEMENT ceremony. Normally mature agile team follow this practice.

Advantages if you do estimation in Backlog refinement ceremony

1. This will help team to understand & clarify stories and features more in depth with PO & BA. This clarity seeking can continue till that story is getting picked up in sprint planning meeting (after it is reached to DOR state).

2. If team does estimation in this ceremony then team end up spending less time in sprint planning. As they have already discussed and understood the story to larger extent.

3. Team understand the backlog well & priority of each feature planned

4. Team knows which all features / user stories are coming up in coming sprints. And team will be better prepared for next sprint planning meeting.

5. When team does estimation in this ceremony; no one knows who will be pulling this story in sprint planning to work on. So team tends to do more discussion & estimate each user story well (as user stories are not tagged to anyone till we go inside sprint planning meeting)

6. Promote shared understanding within team.

Disadvantages if you do estimation in Sprint planning ceremony

1. If team don't do story estimation in backlog refinement; then team will have to spend more time in this planning meeting.

2. Team might not get more time to understand the user stories on last minute.

3. Might not get good estimation as we are doing estimation on last minute with less discussion & less time to understand user story.

4. Unknown components would be more if user stories are estimated without much clarity.

How to do estimation?

The most popular & reliable technique is Relative Estimation. It is very easy and fun to adopt within Agile teams. This technique can be implemented in team through PLANNING POKER card game. I will soon write a blog on it & you can refer that.

There are three attributes of relative estimation process.

1. Estimation Units 2. Relative Estimation Techniques 3. Team Consensus

Let's understand each of them in detail.

1. Estimation Units

In relative estimation technique we use relative Story points for estimating the user stories. The Fibonacci number sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8, 13, 21, and so on. Team is expected to provide a relative estimate in terms of one number from Fibonacci number sequence for user stories. This number scientifically avoids debate or conflicts between team members while estimating.

It is easier to ask 'is that a 5 or an 8? rather than 'is that a 6 or a 7?

A Story point is a singular number that holistically represents below components:

•Volume: How much volume is there?

•Complexity: How complex / hard is it implement?

•Knowledge: What do we know about this work?

•Uncertainty: What is that which we don't know know or uncertain?

This will provides a common basis for a cross-functional team composed of people with different skill sets & experience levels to estimate backlog. Formulate one story as Baseline estimate and compare other stories relatively to it.

2. Estimation Techniques / Process

Team can use Planning Poker game to do collaborative relative estimation. The real purpose of Planning Poker is to promote discussion & collaboration between the team members & get the reliable estimate for user stories so that we can predict team velocity.

All team members have to participate in planning poker & estimate each user story one by one. If we have different estimate from team members for same user stories then team members are encouraged to have discussion & understand the reasoning behind each other's estimate. Then re-estimate & agree on the size before moving on to next user story for estimation.

Scrum Master should facilitate planning poker game, helps to keep estimation activity moving, avoid Debate and promote healthy discussion and stick within the time-box of the sprint planning.

3. Generating Consensus

Purpose of estimation is not just getting the story point number. The real purpose is to promote discussion & collaboration between the team members. Estimating is a Team Exercise which include all team member's perspectives, builds understanding and drives consensus. It creates a shared understanding & commitment within team on what could be delivered. Estimation done by just a Scrum Master or BA or Product Owner or an architect alone will defeat purpose & will not actual intended benefits.

Benefits of relative estimation in agile

• People are naturally better at relative estimation than absolute estimation.

• Relative estimation takes less time and is easy to refine.

• It is designed to be more team oriented

• Easy to explain to others and justify expectations.

• It is easy to adopt & fun to play and keep team interested in estimation activity

*** Please stay tuned for detailed blog on Planning poker game. ***