Story Points, Velocity and How we treat it

People keep asking me about story points, velocity. Can we use it for performance measurement or so? One and half year ago, I would definitly say yes. And today, I will definitly say no. Then why we need story points  and velocity. Most people will ask.

Story points will tell us the complexity of problem. Not actually time that we gona spend to finish it. And complexity of problem can depend on solutions team gona to implement. But please note, we won't be able to give "accurate" estimate because:

1. Story gona to have a change or more which will impact time consumed
2. There will be other distraction can make time consumed one or two times longer
3. We didn't spend time to find every detail of "requirement". there will be 40-70% variance there

Then hey what is planning session for? Story planning's purpose is to

1. Encourage discussion between team members. When there are difference in story points, they are encouraged to have more discussion. (But I normally skip one or 0.5 point difference, if you have different opnion, please let me know)
2. Ensure team to have enough stories to work in next 1 sprint (I normally groom and estimated 1.5 x average velocity load) - that is major reason that we should have velocity, not performance measurement

And in the same time, velocity has been used by me for estimation of project/product delivery with release burndown. I constantly find out that the result is in-constant and not really useful at beginning of project. If you have different experience, please let me know how you have done that.
Post a Comment