While reading Mike Cohn’s article, I came across this comment http://goo.gl/KU6cA What a cool idea when it comes to relative estimation techniques.
If you are to get the benefits of relative estimates, you need to get the relative sizing right (which is a challenge itself). But most of the teams struggle on this. Let me give you an example to illustrate this.
To illustrate this difficulty;
- Team has 20 stories to estimate
- They go through the backlog and establish the base story and mark that as 2 story points
- Then they start from the beginning of the backlog and start estimating the relative size
- 1st story is easy and you compare effort for that against the base story and mark it as 5 story points.
- When it comes to 2nd story, you now needs to compare it with 2 other stories (base story and 1st story)
- This adds on when you go further down the backlog
- What happens is that you loose the sense of stories in the top of the backlog when you come towards the bottom of the backlog. Instead of having one common base story you tend to have localized bases since as humans we don’t have much RAM
There are options to avoid this (such as Triangulation, etc.) but what bubble sort algorithm offers is simple and effective than those.
How you can use is to first go through the backlog and give it a bubble sort. You don’t need to worry about what is the relative size of the story but just compare whether the current story is bigger or smaller compared to next story in the list.
See further http://en.wikipedia.org/wiki/Bubble_sort
If you do this as the start, it will not have the problem which I mentioned above example. Further this will act as a good ice breaker for the estimation session.