Category: Nuggets

Story sizing and 2 weeks sprint

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.

Why now?

As a product manager, prioritizing work with a “Why” is not sufficient. I have seen many PMs or other cross functional team members do this mistake.

They will word-smith and justify why a feature, enhancement or even a defect needs to be addressed.

But a good PM instead leads a discussion with “Why now?”.

“Why” is a necessary condition but “Why now” makes it a sufficient condition.