Get certified - Transform your world of work today

Close

Demystifying Story Points

12 July 2017

Hemant Kothiyal
United Health Group


Software practitioners find it challenging when they are asked to adopt Agile ways of sizing and estimation. I am going to cover some of these challenges and how to address them.

This presentation is divided into three parts: confusion around story points; core concepts of story points and relative estimation; and, finally, how to tackle the challenges.


As I said earlier, story point estimation is a challenge. Here are some issues I've observed while working with Agile Teams:
  • The team equates hours with story points. The story point is about relative sizing and not about relative effort. Effort varies from person to person.
  • Estimating often becomes an individual challenge; while estimating, team members are not necessarily considering the entire team.
  • Irrespective of the team members involved, the tasks required for completion will be same; it doesn’t matter if the people involved are senior or junior.
  • Senior members have great influence, however. Often team members agree with their estimations without much discussion.
  • Some team members just don't participate in backlog refinement.
Story points are a relative measurement of the size and complexity of user stories. That is, a "base story" is assigned some story points to start with, and the rest of the stories are estimated based on their size and complexity compared to the base story.

If story points are an estimate of effort involved in doing something, why not just estimate directly in hours or days? Why use points at all?

I have gone through various blogs and books, but the best answer I found was in Mike Cohn's book Agile Estimating and Planning. He has also discussed this question in his blogs at https://www.mountaingoatsoftware.com/. He says:
 
[Story points] allow individuals with differing skill sets and speeds of working to agree. Instead of a fast and slow runner, consider two programmers of differing productivity.

Like the runners, these two programmers may agree that a given user story is 5 points (rather than 5 miles). The faster programmer may be thinking it’s easy and only a day of work. The slower programmer may be thinking it will take two days of work. But they can agree to call it 5 points, as the number of points assigned to the first story is fairly arbitrary.

What’s important is once they agree that the first story is 5 points, our two programmers can then agree on subsequent estimates. If the fast programmer thinks a new user story will take two days (twice his estimate for the 5-point story), he will estimate the new story as 10 points. So will the second programmer if she thinks it will take four days (twice as long as her estimate for the 5-point story).
Now let’s look into some of the story point-related challenges we face every day, and how to tackle them.








 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.3 (8 ratings)

Comments

sandeep joshi, CSM,CSPO, 7/12/2017 2:09:35 AM
Hi , Good Article , one challenge that i what to discuss is time, within short time of say 2 or 4 hrs , just by reading the 2-3 line user story, its diffcult to estimate, unless and until team drill down in the existing code or functionlity releated to that story , do some research or POC , team is not able to estimate, there may be some unknown area so how to solve this problem ? team always ask for some more detail info in order to have good estimates and just by discussing 2-3 liner user stories, its very difficult to estimate ? has anyone encountered this issue and how you tackle this in meetings ?
Tim Baffa, CSM, 7/12/2017 8:19:33 AM
IT people are historically poor time estimators, but research has shown that IT workers are very good at judging items as larger/smaller than others. That is the genesis of relative estimation.

You do not need to know much about the solution or technical considerations - just judge the size of the story in comparison to other stories. If one story has a UI component, but another has a UI component plus some middle tier work, then the second item is larger than the first, right?

A HUGE benefit of relative estimation is that it can be done quickly, and it is fairly accurate. Have the team perform some affinity estimation (group like-sized stories together, or rank stories in size groupings from largest to smallest).

Keep in mind, and I can't stress this enough, these are estimates. They are the best guess at the size of the story based on the current information at hand. Don't ever hold anyone to their estimate, but if the team's estimates seem to be inaccurate, use that as a potential opportunity to improve.
Hemant Kothiyal, CSP,CSM, 7/12/2017 12:29:42 PM
Hi Sandeep, Thanks for your comment.

I would suggest you to elaborate 2-3 lines into proper acceptance criteria so that team will understand user story scope. During Backlog Refinement session try to find out if team understood scope. Use some confidence scale (1-5) to understand from team how much they are confident on user story requirement. If team is confident they can go with high confidence score otherwise lower score means it require some more details. User story having lower confidence score are potential opportunity to re-size later before team will plan for sprint. But important point here to understand is that even though team confidence score is low they can still size user story relative to other. These relative estimation of user story will help business to understand on long term planning.

I would also like you to setup followup session on lower confidence stories where you can encourage team to have in detail discussion by going through code, database, service etc. But remember don't hold user story sizing during backlog refinement (Grooming) just because team unaware of technical details.

Thanks Tim for your perfect explanation on same.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe