We have been following the SCRUM method for the AGILE projects at Giant Leap Systems. Right from the beginning, estimation is the area of concern and special care was taken to thoroughly understand this process. This was not on account of a lack of knowledge of user requirements or the process in general, but rather because we wanted to do the right thing.
So, here’s how we went about doing that. We used planning poker and Fibonacci numbers to estimate the stories during our sprint planning meeting.
At first, all of it seemed too confusing and it seemed just simple to keep doing what we were used to and just come up with some point system and factoring like x point = x hours or x days, and let's get started. Why bother about anything else.
That would have avoided us the learning curve but, we would have fallen into the trap of keeping track of individual hours and the team coding for the number of hours, days. Exactly the kind of thing we wanted to avoid and that's why we intended to make us an AGILE organization. Moreover, that technique did not align with our ROWE(Results Only Work Environment) policy. I will cover that in another blog.
So, getting back to the planning poker. As a rule of thumb, we refrain from considering absolute time in any sense. Meaning, no factoring in the hours and days at all. Just concentrate on complexity and size. We made sure that this was well understood by all. Probably one of the better solutions for this scenario would have been to use some kind of relative sizings like XS, S, M, L, and XL. That would have avoided some confusion but, we would have lacked our individual team's ability to come out with an average velocity over a period of time. We might still use this in the future and maybe factor points to these sizes to come out with an average velocity of some kind. But, it's planning poker for now with the Fibonacci number sequence.
Comments