I used to be a fan of Story Points, not Anymore
Story point is one of the most popular methods to measure developers’ workload during sprint. It is flexible but could be rigid at the same if it is used correctly. Because of this, I loved it and always encouraged its use in software development for fair estimations to both developers and business people.
Well, I said it in the past tense because I still use it, just don’t like it anymore
Let me explain:
In theory, the use of story points is used so developers can work to the maximum of their capability and prevent unachievable commitments. But, it must not replace the Sprint Goal. The team must always focus on Sprint Goals, while story points are only there to limit developers’ work so they don’t overwork
The thing is sometimes the team focuses too much on story point, burndown chart, etc. This makes them think they succeed in the sprint even though the sprint goal is not achieved.
Don’t get me wrong, story point is great but focusing on it too much will lead you to the wrong path. Especially when you decide to use other agile frameworks such as Kanban
So, what to measure instead?
I suggest we return to the original, the goal, or if you use Scrum, the Sprint Goal. So instead of checking the burndown chart, the team checks on the progress of the Sprint goal. That way, the team can focus on achieving it and willing to shift their activities, in case of just getting things done and lower their burndown chart
Don’t get me wrong, I still use story points once in a while to quickly get a big picture of whether the team achieved something the day before. It is still useful
In summary, using story points to measure your developers’ work is alright but you shouldn’t replace the Sprint goal with story points. The team should always be encouraged to pursue and achieve the Sprint goal. Only then, will your team and you get a meaningful goal to accomplish and share.
