I've been working in Agile environments for almost 6 years now and I still manage to learn everyday! Recently, for instance, I came across one reason why story points are a good measure for planning. We had a list of stories whose complexity the team had estimated in story points; however because we were at the beginning of our release, there was a high number of unknowns (which we addressed by creating spikes). We use to divide a story in tasks and to estimate tasks in Ideal Engineering Hours (IEH); however due to the number of unknowns, we didn't know all the tasks that would make up each story.
We had on the one hand a list of stories for which the team had a "feeling" about their complexity and which estimated considering the "complexity" of each story, and on the other hand a great number of spikes to identify tasks.
Thanks to the fact that the team estimated the complexity of each story, although it couldn't estimate all various tasks, allowed us to select the stories to address for the coming Sprint; hadn't we estimated stories in Story Points, we would not have been able to have a "feeling" for how many stories we could have committed to, because the number of tasks actually known was very low.
Morale: I learned that one of the true values of story points, as a measure of story complexity, is that they allow the team to plan an iteration even if the tasks to complete each iteration are unknown, so they are a great planning tool.
Of course, the outcome of different spikes could very well be that a story is ways more or ways less complex than originally estimated; that could however happen even if all tasks were known when planning the iteration (for instance because a high number of unknowns emerged during the Sprint, or the team realised that not all tasks originally planned were actually required). However having story points allowed us to provide an iteration estimate even if we didn't know in detail everything that was needed to complete that iteration.
Recent Comments