So a bit of a break in my postings as I have been traveling to warmer climates. But I am back in the swing of things, which includes continuing ed credits for my PMP. I actually really enjoy the opportunity to watch these webinars as I find I learn and get a lot out of them.
A recent one I just finished was going over how to estimate Agile story points, so I thought I would share.
Basically in each iteration the goal of the team is to implement “story points” that are generated from the product backlog. These are put into order of priority. The number of stories worked on in each iteration really depends on the amount of time and effort it takes to fully complete each story.
Makes obvious sense, right? The issue or trick, of course, is how do the teams estimate the size and scope of each story. The one important thing I have come to learn is that although in traditional projects it is very common to estimate hours for each task or effort, this is not usually done in an Agile environment. Of course, some of the presenters were discussing hybrid approaches so nothing is ever black and white, but for the most part it holds true.
With Agile the more common method is to use a technique called “story points”. Story points are a theoretical method of estimating the relative complexity of implementing a user story. Depending on your organization, each project team usually establishes their own story point scale. For example if the team thinks story 1 has 5 story points and they think user story 2 will take twice as long to complete, then story 2 will be assigned 10 story points. There is no true set formula for story points. The above example could easily be 25 and 50 story points. The only thing you have to know is that story points represent the relative sizing of the user stories. That is a fairly easy concept to understand, the method of doing so just depends on how your organization structures it.
Then the rest flows pretty logically. Once the team knows the size of the story points, they know how many they can deliver in each iteration (iteration length having already been determined, of course). If the story is too big for the iteration, then it needs to be broken down again to fit the iteration timetable.
It was a really interesting and easy to understand concept and I can obviously see how transferable it would be to many projects, while at the same time not being a technique that would be easily used in a more traditional waterfall project.