Metrics Misconceptions: Does Story Size Matter?

As a Scrum Master of the team, I often raise questions to stimulate the team’s discussion and improve their understanding of Scrum and other frameworks or practices we use.

“It’s Thursday and the fourth day of our 5-day Sprint,” I said, “If I pull a Product Backlog Item from the Backlog, I have to finish it by tomorrow, or else the Work Item Age will be increased by 2. Should I pull it or slice it to guarantee I can finish it by tomorrow?”

During the Sprint Retrospective, one team member wrote, “Does story size matter?”

As a typical consulting-style answer, I probably answered, “Yes, and no.” However, I stayed silent and let the team discuss this topic.

Time to Market is one of the Key Value Areas described in Evidence-Based Management. Cycle Time is the Key Value Measurement that falls into this area. We should reduce the Cycle Time by slicing the work item into the smallest possible to validate the value sooner. This can be done by actively managing the WIPs.

Some organisations misunderstand the concept behind the metrics and thus misuse them. The team may feel afraid of management weaponising them. Let’s say 50% of the work items of a team are done in four days. If someone starts working on an item on Friday, two days will be wasted, and its Cycle Time will be longer than 4 days. The team may get blamed.

Organisations should understand that all the metrics are not for reporting outside the team. No one should be praised or blamed whether the metrics are “met” or not. The metrics are only a reference for the team to guide their understanding of the product and themselves. The team would use them together with empiricism to increase the quality and effectiveness.

“If you are concerned that the Cycle Time drops, just don’t start a new item,” one of the developers said, “There is still a lot of work to do. Look at those technical debts and automated tests.”

Teams run into situations from time to time where they want to quickly test ideas to improve the Current Value or lower the Unrealised Value. We admit that this is a necessary evil. This usually incurs technical debts and hinders the Ability to Innovate in the future.

If starting a new item hampers the Cycle Time, fixing the problems or improving the quality are the options near the Sprint ends. A highly efficient team does not guarantee highly effective work. We are not a feature factory. It is important to balance the Time to Market with the Ability to Innovate. Without these two Key Value Areas being balanced, it would be difficult to deliver value to the customer in high quality.

So, does story size matter? Yes, you should slice the work items into the smallest possible. But you do not slice them because of the metrics or holidays. We should work towards the Sprint Goal, rather than working for the metrics. If you can’t finish the work on Friday, just let it be. A single work item will not seriously affect the metrics since the Monte Carlo Simulation has already taken it into account. If you are too tense about the metrics, you will face backlash from them.