Useful Tips to Explain the Story Point Logic to Scrum Teams
In this article, I want to offer useful tips that you may want to try with your Scrum Team.
We all know that one of the most challenging practises of Scrum is “The Story Points”. Possible questions that you might get from Scrum Team Members include:
- Why should we give the Story Points?
- For what purpose will I use it in the future sprints?
- Why should we vote together? Shouldn’t I just vote for the issues related to my area of expertise?
I won’t explain the basics of the Story Point subject in this article. Instead, I will dive deeper by trying to answer the third question specifically, because we can find lots of useful documents/forum topics which explain the first two questions. But the last one, in my opinion, is the most challenging one for a cross-functional Scrum Team.
“Why should we vote together? Shouldn’t I just vote for the issues related to my area of expertise?”
If you work with a Component Team like Backend, for instance, you might not encounter this question. But if you work with a Feature Team, you probably will. Here, you can consider two main approaches; the first one is the philosophy behind it, and the second one is the analytical logic.
The first approach is easy to explain. We all know that we commit to Sprint Goals together in the Sprint Planning, and we are all accountable. All issues are the team’s items, ownership belongs to the team, not to a specific member. Our point of view should be product focused as a whole. If we vote separately based on our expertise, then a perception of individual ownership comes to our mind in the long term. That’s not the thing that we want to see in a Scrum Team.
The second approach is about explaining the analytical logic behind Story Points and it really makes sense for a cross-functional Scrum Team. I want to explain this logic with an example to make it clear.
Assume that you are in a Refinement Meeting with your team and you are checking the Product Backlog with all members. You have four ordered items (visualized as four gift boxes given above) and assume that their sizes are equal. These issues can be based on Frontend (FE), Backend (BE), WEB or a story with sub-tasks, it doesn’t matter.
FE engineers came to a consensus on the FE issue and voted as 5, because they can understand each other and decided that “5 story points is OK for them”. Next is related to a BE issue. Now, BE engineers thought that only they should vote for the BE issue (because they know this issue very well), so they voted as “21”.
What happened? The same boxes, but different story points.
In this case, if we record the team’s velocity as X value after several sprints, is it correct? Can we use this data for planning the sprints? No :( Because how many boxes will you take? You don’t know.
One of the important reasons that we should vote together is because of this approach. We should try to give the Story Points close to each other and create the team’s references day by day. There is no universal 5 or no universal 21. It won’t be easy the first time, but team members should ask detailed questions to each other to understand the size of the item and learn lots of new things sprint by sprint. In this way, we can increase our level of knowledge by brainstorming. After that, you will probably get closer votes on Scrum Poker naturally.
In the end, I want to highlight that Story Points are just tools that can help you with forecasting in the Sprint Planning and Refinements. Of course, you may find your own alternative ways. I just wanted to give useful tips for Scrum Teams who use Story Points. I would be very glad if these approaches help you to explain the logic behind it.
