I was part of a discussion where an argument between various members belonging to Engineering, QA, Scrum Masters, Product Managers and Release managers were debating about what should be the max size of a story. That forum wanted a “hard” limit of 5 days for a story – primarily because it will enable them to move to 2 weeks sprints from a current 1 month sprint cycles.
Here’s my take.
The reason we do Agile is to ensure that we get Predictability (in the form of feedback, reviews, validation etc). And predictability in two important dimensions
- Direction : Are we building the right thing?
- Time : Are we spending right time and on-schedule?
So, it’s not important if the MAX story size is 4 days or 5 days in a 2 weeks sprint. What’s more important is to understand whether a team is able to commit and deliver the body of work in a given sprint so that those Two important dimensions can be evaluated – Direction and Time.
As a guideline and best practice, we can suggest the individual teams that they should try to have smaller stories, leverage INVEST principle and all the other agile frameworks.
However, what should not forget that the objective of the process or any methodology is to help reduce chaos – and not bring rigidity. So, if a team has average story size of 6 but has high commitment to completion rate in a given sprint, then they should be free to stick to max story size of 6 days. If another team sees that keeping the story size to 4 days is better, then so be it. Infact, review or retro time could be leveraged to analyze a story which couldn’t be finished in a sprint to understand if there is a repeated co-relation between size and not getting done. May be a co-relation will appear that a story in a particular area if is more than x days, then the likely hood of it not getting completed in a sprint goes high. Then may be the Product owner should ensure that they breakdown the work in that particular area.
A blanket 5 day max rule across the board is not the right approach to agile.