As a result of constant changes in requirements and technology, software development is challenging and potentially unpredictable. Also, people are at the heart of everything we do and are highly unpredictable as well. Several considerations that help product owners make choices that impact the whole team and the organisation must consider. The problem is that product owner and clients require such forecasts to make the most of their budgets and evaluate the business value and when results will be available. There are different ways of estimating the development of a project. One approach is utilising Story Points. Although such estimation may not be the simplest, estimating with Story Points in Scrum provides advantages for both developers and stakeholders.
This post will discuss the worst situation about Story Point in most of the Scrum Teams I have seen and heard.
Story points are a measure to express a total effort estimate that would be appropriate to implement a product backlog item completely. In other words, a story point is a number that tells developers about the complexity level of the story.
I have noticed that after completing the item and delivering it to the customer as an increment, no one pays attention to whether it was estimated correctly from the beginning or not!
I have had this experience and heard from other scrum masters that sometimes an item with high-value story point, less than an item with low-value story point, took work and effort and vice versa! It seems that when the task completed, it does not matter what happened! Why? Because the value team need, now has delivered to customer! In my experience, the reasons for incorrect item estimation can be:
- Satisfying stakeholders, including Scrum Master and Product Owner.
- Using estimates for analysis.
In the team where I work as a Scrum Master, we usually look at these issues when the estimate is very wrong, and there is a big difference in time (more or less) with the item in the retrospective meeting. The purpose of this is to find out about the challenges and problems we have not been careful about them. This approach allows the team to plan better in the future. All this is to improve the Scrum Team’s synergy, which ultimately benefits the stakeholders as well.
Thanks for reading the Scrumsaturday.com! Take a minute to follow me on Twitter if you enjoyed this post and want to see more.
Leave A Comment