You might have often heard a Scrum master ask “Story points are not equal to time?” Why does this question arise?
Consider a situation where two Scrum teams working on the same project. In such cases, organizations usually expect a common measurable scale to compare the performance of their teams. This is where the problem starts. For instance, Scrum Team A assigns 3 story points to a baseline user story such as “Create Login Screen.” Whereas, Scrum Team B may assign 1 story point to a similar baseline story.
Assuming both teams are performing at par, Scrum Team A will end up completing more story points compared to Scrum Team B just because they allocated higher points to their baseline story. Therefore, to put up a common scale of measure, many organizations end up creating a matrix to equate story points with time.
The essence of SCRUM
In my opinion, this should not be the case; as ultimately, the output is what should matter the most, not the hours spent. When multiple teams work together, the common scale will determine how well they are performing. But, equating story points with time will deviate from the philosophy on which Scrum is based – an iterative and incremental way to handle complex and that conditions required to perform a task cannot be decided upfront.
The iterative, adaptive, and flexible process in Scrum is a way to ensure the deliverables are designed according to emerging requirements. And, assigning complexity to a task is only one way to determine the estimation of both time and effort to do the task and hence, cannot be equated with time alone.
Measuring progress
How do we measure the progress then? A committed team, working closely with the customer to understand their needs, priorities, and adapting to the changes, should be the true measure of success. Not everything requires to be quantified. Sometimes quality and commitment have to be felt, not just seen or measured.
Unfortunately, we live in a world driven by numbers and metrics and hence it’s essential to have a common matrix defined, especially when multiple Scrum teams are working towards similar user stories.
Here’s how I have tried to address the demands of clients and organizations:
- Have a common baseline user story with the same story point, assigned across multiple teams
- Maintain same sprint duration across teams
- Maintain same team size and structure of the scrum team
- Most importantly, having a common mentor across the teams who help define and establish common processes for e.g. estimation, the concept of ‘Done’, the ceremonies, etc. as all these add up to the efforts and can lead to variation in output
I will be happy to hear your thoughts on this topic. Please write to itservices@healthasyst.com
In the next blog in the Scrum series, I will discuss some of the challenges that organizations could have in adapting to Scrum and how to solve them.