Agile Estimation - Demystifying Story Points In Most Easiest Way

What are Agile Story points?

Story points in Agile represent 3 important factors – work complexity, the amount of work, and risk or uncertainty.

It’s just not about the clock.

• Story points in Agile are units of measure for expressing an estimate of the overall effort (!= time!!!) required to fully implement a product backlog item or any other piece of work. 
• When the development team conducts an estimation, it is recommended to abandon the traditional “human-day” assessment method, using the point of the story point, We use Fibonacci number (1, 2, 3, 5, 8, 13, 21…) to estimate the story point
• It should represent 3 important factors – work complexity, the amount of work, and risk or uncertainty.
• It’s a relative estimation, not absolute, meaning that we should not only consider the time factor while estimating in Agile.
• Agile Story points are coarse grained , relative measures of a raw effort and size. An item worth 1 story point is half of the size of an item worth 2 points. An item sized as 3 points requires as much effort as an item with one point and an item with 2 points added together!
• Relative measures take advantage of the fact that size itself is relative: the semantics of big and small depend on our reference point!

How will we do it?

I mostly try thus 4-step approach to stream line the mindset of engineers in the team. Yes, of-course, it’s all about the mind set. Its never a right answer, but when you do this repeatedly, your team will get better at estimating the effort.

Step 1 – Reference Stories

• Some sample stories that could represent a few of the first Fibonacci numbers like 1,2,3, and 5. We only want to keep it upto 5, so that no story or task would be too large as 8. It will promote culture of breaking down tasks to granular piece of work
• Use it for reference in first few estimation, eventually you won’t need as you would be more comfortable with reference points

Step 2 – Apply Cheat Sheet

Step 3 – Triangulation

Triangulation is checking not only a reference of the same number but the two around it. For instance, if you consider an item to be a 5, get a 3 and an 8 and see if it really is in between those.

Step 4 – Planning Poker

Planning poker is a common practice across the many tech companies. The team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate. Then everyone shares the number one after another that reflects their estimate. If everyone is in agreement, great! If not, take some time (but not too much time–just a couple minutes) to understand the rationale behind different estimates.

When a team member is justifying his/her own estimation, use Step 1’s reference points and step 2’s cheat sheet to explain rationale behind certain estimation. There are many planning poker tools available on the internet. Since many teams are now remotely working, using the zoom/teams/Google Meet Chat function, you don’t have to introduce another tool just for this.

How to do Planning Poker?

1. Post proper understanding of task on what exactly needs to be done, Everybody types their vote into the zoom chat and on the count of 0 everybody presses enter
2. The team members with the highest and lowest estimate start right away sharing their ideas/reasoning behind their estimate (everybody else can add  their opinion as well, of course)
3. Post short conversation, We will rerun the vote and usually the estimates will be much more aligned (also comparing to reference stories might be a valuable tool)

Some other agreements you can have during Planning poker:

1. If there’s an disagreement after second vote, We will go with the higher estimation (rather under- than over-commit in the beginning)
2. After each voting round, somebody puts a “separator line” into the chat (can be just 3-5 “–” or something, just to have visual break between the votes)

The fun comes from observing who will be the first when the count-down is at 0 or also nudging the one who might be late with the vote (potentially trying to get a sneak peek of the others’ votes). A big advantage (compared to using 5 fingers or planning poker cards) is that the votes stay visible – so it is easier to drive the conversation (e.g. between highest and lowest vote) We use Zoom chat because we don’t need an extra tool and switching back and forth between tools (except perhaps between chat and jira), which makes it also easy & lean. 

A few things to note:

1. In Agile, We break down tasks with multiple tasks if it’s equal or higher than 5. No single story/task in the sprint should be higher than 5, if it is, break down to multiple tasks.
2. Use subtasks in the case where one ticket requires 2 (or more) PRs that need to be worked in parallel.
3. This guide is just a common understanding around sizing the story in a uniform way within a squad, if you are following the Agile. You can tweak it, modify it to best suit your requirement. This is just a guidance to start with.
4. Team members can look at this cheat sheet while planning and come up with their size in story points. The discussion from there should happen on the difference in understanding of these 3 parameters and not the story point as a whole.
5. Always estimate in story points in Agile, even when estimating RFC for the first time. Whenever we need to estimate something, a new epic will be created, and you will break down the RFC in stories/tasks to estimate. We will not use documents and efficiently use Jira so PM won’t have to break it down to tasks, and same tasks will be used during grooming meetings. Estimate each story/task with Story points.
6. Give preference to the team member’s estimation who is actually going to work on the task, in case there’s a conflict.