Big is bad, small is good!
The case for small batches in product development: why large work items slow everything down, and how reducing batch size consistently improves flow, quality, and predictability.
While a lot of what affects an agile team is within the team’s scope of responsibility, the key antipattern I’m talking about today sort of isn’t…
A big factor on whether a team can be effective is the size of stories/features on its backlog. A lot of good things happen when stories are Small (See the S in INVEST). A lot of bad things happen if they’re too big.
Lets look at how it looks when the stories/features are too big (team takes more than a week or so to start-to-finish them)
Teams cannot achieve real flow – testers are idle waiting for a long story to be developed, then are stressed to test it, since the end of the iteration/sprint is near.
Since there is a tendency of individuals to want some ownership of at least a story (if not a module), assuming big stories, an iteration/sprint will look like a mini-waterfall, with the developers each taking a story, all major stories getting into testing about 2/3 of the way into the sprint, and we lose the ability to control the sprint scope, and left with either making it across the finish line after managing to catch all defects and fixing them for all of the stories, or we are left with a sprint which is unsuccessful. The burndown chart of such a team will look like the one below.
For some really big stories, its not even clear how to finish them in one sprint, so teams start to have sprints for “Design”, “Coding”, “Testing” leading to really a waterfall across sprints.
With both in-sprint and across-sprints mini-waterfalls the mains problems are visibility and ability to change priorities or adapt to new requirements.
From the moment you start working on a story/feature, it becomes WIP – work in progress. Your aim should be to minimize this. WIP is Waste, that becomes apparent in the cases your Product Owner comes and says that this feature is now not the top priority anymore and he needs something else instead, or that after seeing a demo first time at the end of the sprint, he has a lot of changes in mind that you would have liked to have known about before finishing all the work.
The visibility problem is due to the fact that the real measure of progress is Working Software. Knowing that the design task is done and we are in coding is nice, but after many years developing software we don’t trust it that much. We prefer seeing working software frequently DURING the sprints.
The one potential problem of really small stories, is that they become a unit of business value that doesn’t mean much for the Customer/Product Owner. The drive for “Minimum Marketable Features” adopted by Kanban is to have slightly bigger stories, something you would mention in a product blog for example. There’s a fine balance that needs to be managed here.
Moving from agile theater to real business agility takes more than a framework. Explore Business Agility advisory or let’s talk.
Practical thinking on turning AI pilots, adoption, and portfolio work into business impact - by finding the constraint, changing the work, and proving value as you go.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →