Traditional exhaustive estimation sessions are on the rebound within development teams. They have started adopting relative measures, known as Story Points, in order to become more effective in the estimation session and more precise in planning their releases.

Story points are a relative measure that can be used for agile estimation of size. The team decides how big a point is, and based on that size, determines how many points each work item is. To make estimation go fast, use only full points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65 points. To get started, look at 10 or so representative work items, give the smallest the size of one point, and then go through all other work items and give them a relative point estimate based on that point. Note that points are used for high-level estimates, so do not spend too much time on any one item. This is especially true for work items of lower priority, to avoid wasting effort on things that are unlikely to be addressed within the current iteration.

Benefits reported by team members after adopting story points:

• Better planning for Product Owners
• Overview of team capacity, team velocity and coming tasks
• Reduction of idle time
• Higher efficiency at planning / grooming
• Once the concept has been adopted in the team – estimates can be given promptly
• Simple process
• Team members have a shared understanding of size than when estimating in hours
• Better release predictions and team commitment to the plan

More accurate release plan both internal to the team and external to the product owners etc

Case: Team working with corporate banking systems

The team has successfully adopted story points and have been using it for a longer period. The PO is responsible for assigning business value to the user stories for the coming sprints. After scoring each user story they are presented at a refinement meeting with the team where the stories are discussed while adding priority/rank and story points.   The team will subsequently break down the user stories and estimate them at the sprint planning session. In order to reduce idle time for team members they estimate up to an order of 120 % of their capacity. The top 80 % highest prioritized items are planned for the coming sprint while the remainder is planned for next future sprint. If the team succeeds to complete all planned tasks in the sprint, they will autonomously transfer tasks from the next future sprint into the current sprint.

Case: Team working with document systems

The team has successfully adopted a variant of story points and uses the terminology of ideal working days. In this case they have defined that a team member can complete 8 story points per 14 day sprint (i.e. one story point resembles approximately 1 ideal working day disregarding department meetings and other events occurring outside the team). To be able to estimate properly with story points, they have decided that items should be broken down to chunks in the range [1;13] and that items receiving a story point score >= 20 must be broken down further before development.   The team has taken advantage of the story points and are now able to do better release planning. Their average team velocity is approximately 36 story points. This means that they can plan a 100 story point release to be implemented in the course of 3 sprints. 

Please note that converting story points into values that are relateable to hours, working days, etc. is not ideal but can be a way of starting on relative estimation.