Q: Story points are useless?
What is a story point ?
There is no clear definition found online about story point, not even in the online scrum guide. Different people and teams have different interpretations of this term.
In general, story point is a method for the team to estimate the complexity and effort to complete the requirement. So the main objective is for estimation for the team to quantify the backlog items.
How does the team make use of story points ?
In backlog refinement, the scrum team will normally use the Fibonacci sequence (Planning Poker) to evaluate the story and give an initial estimation of the story point based on the experience that counting against the complexity, risk, impact and uncertainty. It may undergo alignment between members to reach the conclusion of the final story point when there are conflicts or huge variations.
If the story point is too large, it becomes a sign to break into small stories in order to have a less complicated or feasible story with less risk.
In sprint planning, scrum team will base the past story points consumed (velocity) and then decide how many stories can be added into the upcoming sprint. It also became a way for the product owner to estimate and prioritise the product backlog.
In sprint retrospective, the scrum team will retrospect on the performance such as story point burnt down chart. The team will review whether an unexpected estimation over the effort/complexity or how we can improve better. Especially, the result may not be perfect for the forming/storming stage. But the story points consumption should always be independent of time spent, it may reflect better with more story points in each sprint theoretically.
Why do people think story point useless ?
There are different perspectives on these controversial topics.
In the view of developers, the high learning curve or understanding on concept of story point is very hard. It happens to the senior team members dominating the story point estimation because they have a bigger picture/understanding of the items. However, they aren't the only development members who work on the task so it becomes big variations on the result. And it leads to another situation where the junior member is afraid of giving their story points in the meeting to prevent any conflicts or explain the reasons. As a result, inaccurate/unreliable story points are given and become a daily routine to go through "scrum events".
Even if the member is getting mature enough to give the story point, the whole process may be time consuming and the outcome is not satisfied with a time-boxed meeting.
The team may even think of the commitment and fail to deliver the stories at the end of the sprint. So it is common to leave more buffer for the story estimation. Another involvement/blame from the stakeholders or boss may cause the story points to become inaccurate (even though the story points are a relative estimation to other stories). I have seen cases where the boss is asking for a story point increment in each sprint as KPI which may further affect promotion/bonus.
In the product owner's view, story point becomes the only way for them to estimate the upcoming sprints and roadmap of the product. Although the story point gives a very rough picture from the scrum team, it needs to reflect the business values or insight to the final boss/stakeholder. However, the misalignment on agile (scrum) between senior management and the scrum team is holding different belief over the scrum and agile. On one side, they believe agile will give a better outcome and efficiency that earning more money than the traditional waterfall SDLC. Even though scrum master should advocate the concept of agile to the boss but it is extremely hard and rarely sees success cases.(especially in the asian culture, they have invested a lot into this new trend but turned to have a poor return)
Is story point useless ?
I will say yes but no. Just like scrum is a framework and no concrete approach on how the team puts into practice. There is no right or wrong approach to using.
Yes, it is useless when the team is just forming without any concept over agile values. There are many companies claiming agile (scrum) but turning out without "WE" and just focusing on the individual benefit within the team or outcomes only. With an improper mindset like the alignment/commitment issues mentioned above, story point is just a time wasting process.
Someone(AF) may prefer spending time on the story refinement. (However, we shouldn't compare them together since they are totally in different aspects). The story point is for estimation that should be compared with other estimation methods such as time based estimation/T-shirt size/no estimation at all. Because no matter which estimation is used, the story still needs to be refined properly. (or break down if needed). And I can't think of how to perform sprint planning to judge how many stories. (Just based on the number of stories that we used time to break down into very small ???)
In fact, if applying another time estimation method, the same situation like inaccurate/unreliable /commitment/time consuming issues occurs again. Different opinions on the T-shirt size evaluation or time estimation happened due to inexperience or lack of knowledge. So it is independent of the method we applied. In addition, I can't find any scientific research about the efficiency and values of which one is superior.
In fact, if applying another time estimation method, the same situation like inaccurate/unreliable /commitment/time consuming issues occurs again. Different opinions on the T-shirt size evaluation or time estimation happened due to inexperience or lack of knowledge. So it is independent of the method we applied. In addition, I can't find any scientific research about the efficiency and values of which one is superior.
If you are talking about spending more time on refinement over story point, then it will be time management and usage issues.
In fact, no matter which estimation is applied. If it doesn't change the core values of the team and company over the agile. Those scrum events are just useless and time-consuming. Everything is just inefficient and inaccurate at all eventually. And the main point, estimation is just a very rough picture of the stories for reference. It needs tons of time to improve the accuracy and tune the usage.
However, it doesn't mean we shouldn't start the culture and exploration. Just try & error to find out the suitable way to fit into your team and company. I do have experience with the team treating story points as hours (i.e 0.5 story point = 4 hours). It sounds like there is no difference between a story point and time based one but it gives us the relatively effort and burn down chart at the end.
Conclusion
Story point is just an estimation tool suggested and thus no right/wrong itself. If we apply in the proper way, then it will accelerate the flow and accuracy. I will suggest try & error and find a way that everyone feels comfortable. Please bear in mind that there is no prophet or 100% accurate estimation in reality.
Especially, if you are searching this topic on the internet, you may feel hesitation and are trying to find something to support "useless story point". Then just use another estimation method (time based, no use estimation) that you like.
At the end, thanks for reading my 9up.
(Today is not a perfect day but this is life.)
(Today is not a perfect day but this is life.)
.png)
留言
發佈留言