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.