Wednesday, April 24, 2013

Practical Scrum - Story Point Estimation

This blog is about how to come up with a release plan using story point estimation technique. I am writing this blog while I am working on sprint 4 of our project. We are following a two week sprint cycle and our project will be completed in Sprint 8. When I say sprint 8, it’s the commitment from my entire team and we have not estimated any of our tasks in hours.

I am the tech lead, developer and the scrum master on my team. I also write integration tests. Scrum master can be a dedicated role as well as shared one.

This blog assumes that you understand scrum, so will not explain what a story point is or what velocity is. In a line, Story Point is an abstract measure of size of user story and velocity = total story points burned in a Sprint.

This is how we began to estimate our Release date. We added all our stories to product backlog. We use Jira as scrum tool. The stories were then prioritized and based on priority, we selected 30 user stories for our first release. These story names were then written on sticky notes. Then we called for a release planning meeting.

This meeting happened four times with a duration of 1 to 1.5hrs each. Participants were the entire team which is three developers (including me), 1 tester and product owner. We used Fibonacci sequence as story point estimation technique. We gathered in a room, sat on a big oval table and created 9 virtual columns. Column headers were 1, 2, 3, 5, 8, 13, 20, 40, and 100.

Product owner picked a medium complexity story (complexity was decided by me as medium). Then he started explaining what that user story means, what all it involves and when will it be considered complete. All team members asked questions to get more clarification. Ultimately everyone’s query was answered. Team discussed that as part of this user story we will need some UI changes, a new method in business logic, some normal stored procs and roughly 2-3 automated integration tests. They trusted me that based on entire stack it is a medium complexity and placed it in column numbered 5.

Then we picked next story, product owner explained and team asked questions and thought among themselves that what will be required technically at a high level. They concluded that this story is less in complexity than previous one but was not very straightforward too. As it was low in complexity so it was kept at column numbered 3 to the left of column numbered 5.

Next story went to column numbered 13 as it was more complex than the one we placed in column 5. Next went to column numbered 1 as it was the easiest one. Then the next story was thought of between 13 and 20, but as we did not have any other column, I asked team to put it in 20.

The stories which went to 40 or 100 was discarded by me. I asked product owner to break these further before next meeting so that each short story is 20 or less. There were few 13 and 20 numbered stories which logically could be split to shorter independent ones. This was done instantaneously and the new stories then moved to 5 or 8 numbered columns.

Before you get bored, let me say that this went on and after 4 meetings, all release 1 stories were in one of following columns 1, 2, 3, 5, 8, 13, 20. During these discussions, some moved to backlog and others were picked from backlog by product owner as he got more understanding from team inputs.

Team again trusted me and kept iteration length as 2 weeks. We started coding sprint 1. We did a sprint planning meeting. How we did it will be covered in another blog. At end of sprint 1, we checked how many stories we completed. We completed two from column numbered 5, one from column numbered 13. Total sum of story points completed in sprint 1 = 2*5 +13= 23.

In sprint 2, we completed 20 and in sprint 3, we did 22 story points.

From this we deducted that we are doing an average of Math.Floor((20+22+23)/3) = 21 story points in one sprint. We have total 160 story points estimated in our Release 1. So with 21 as average, we should be done in sprint 8. Each sprint being 2 weeks plus schedule and feature buffer, we now have a release date with us.

This is just one of several methods of estimating a scrum project. Others are via historical results, or via forecasting by deducing hours as documented in Mike Cohn book Agile Estimating and Planning chapter 16.

In this blog, intentionally to keep it simple, I did not explain sprint planning meeting and also did not talk about certain things like project schedule buffers, backlog grooming etc..

I will extend on few of these points in part 2 of this blog.