What is a Story Point?
A Story Point is a metric used in Agile Project Management to estimate the difficulty of implementing a given user story, which is an abstract measure of effort required to implement it. In simple terms the Story Point is a number that tell the teams about difficulty level of the story. Difficulty could be related to complexities, risk and efforts involved.
Story Point estimation, a kind of relative estimation, is typically performed at Product Backlog Grooming Sessions.
In order to make the Sprint Planning more efficient in practice. PO and the team will make a rough estimation called product backlog grooming before the Sprint Planning and check for:
If the Sprint Plan is readily to be conducted efficiently?
Is there is enough information to complete these matters?
Is the user story split reasonably?
Fibonacci number for Story Point
It is recommended to abandon the traditional "human-day" assessment method, using the point of Story Point, using the Fibonacci number to estimate the Story Point.
The fibonacci sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8, 13, 21, and so on. Teams use this sequence, rather than a linear 1 – 10 as it forces them to provide a relative estimate. Easier to ask ‘is that a 5 or an 8?’ than ‘is that a 6 or a 7?’. This is a similar problem to the ideal hours described above.
Story Points vs Hours?
Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to Story Points. Story Points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other pice of work. Over times, this helps teams understand how much they can achieve in a period of time and builds consensus and commitments to the solution.
It may sound counter-intuitive, but this abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons to use story points:
Dates don't account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in.
Dates have an emotional attachment to them. Relative estimation removes the emotional attachment.
Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon.
Once you agree on the relative effort of each story point value, you can assign points quickly without much debate.
Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value
How to estimate the Story Point?
There are a fews techniques to estimate the Story Points, such as Planning Poker, T-shirt sizing,... However, I would like to recommend the T-shirt sizing techniques.
What is T-shirt sizing?
T-shirt Sizing is one of the Story Points sizing techniques to estimate user story usually used in Agile projects. Rather than using a number of planning pokers, here, items are classified into T-shirt sizes: XS, S, M, L, XL.
With T-shirt measuring, the development team is made a request to evaluate whether they think a story is extra-small, small, medium, large, extra-large, or double extra-large. By expelling the numerical score, the development team is allowed to think in a more dynamic manner about the exertion associated with a story.
Smaller than XS = a Task
Extra Small = 1
Small = 2
Medium = 3
Large = 5
Extra Large = 8
Larger than XL = an Epic / separate into different story
This is a very informal strategy and can be utilized quickly with a large number of items.
It is a popular agile relative estimation technique.
Forcing the estimate into one of a fixed set of sizes allows the process to go quickly.
It is a good way to introduce terms to relative estimating.
It is very effective for affinity estimating.
Unfortunately, Story Points are often misused. Story points go wrong when they're used to judge people, assign detailed timelines and resources, and when they're mistaken for a measure of productivity. Instead, teams should use Story Points to understand the size of the work and the prioritization of the work.