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

Story Points

Reference Functional/non Function Requirement

0.5

Change configuration in app config, Deprecating feature flags

1

Minor UI changes, Adding a feature flag in one place or adding some new fields and parsing them in API contract, IaaS changes

2

Implement some UI changes, Modifying & Implementing API contracts

3

Implement complex UI display, Adding a new API endpoint

5

New Features broken down to smaller pieces of work

Table 1: Reference stories

Step 2 - Apply Cheat Sheet

Uncertainty

Complexity

Effort

Points

Small

Small

Small

1

Small

Small

Medium

2

Small

Small

Large

5

Small

Medium

Small

2

Small

Medium

Medium

3

Small

Medium

Large

5

Small

Large

Small

3

Small

Large

Large

5

Small

Large

Large

8

Medium

Small

Small

3

Medium

Small

Medium

5

Medium

Small

Large

8

Medium

Medium

Small

5

Medium

Medium

Medium

5

Medium

Medium

Large

8

Medium

Large

Small

5

Medium

Large

Medium

8

Large

Medium

Small

8

Large

Medium

Medium

8

Large

Medium

Large

13

Large

Large

Small

8

Large

Large

Medium

13

Large

Large

Large

13

Table 2 : 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.