By Nick Butler
Tags: Agile , Development
Reducing batch size minimises the risk you’ll miss time, budget and quality targets. This case study shows how one Scrum team was able to manage risk by splitting stories into vertical slices of valuable functionality.
It’s part of a comprehensive guide to Project risk management with Agile and follows on from my post on how to reduce batch size in Agile software development.
The case study covers a long-term project we’ve worked on to continuously improve a complex, multi-part web application.
It’s a great project. The work is varied, the client’s outcomes are tightly aligned with our mission of making a positive and lasting impact, and the Product Owners are knowledgeable, responsive, passionate and fun to work with. The high level of trust across the Scrum Team has helped create an effective and enjoyable working relationship.
We define our backlog items as user stories and we’d noticed that we’d had a number of big stories recently. It was a trend we were keeping an eye on. That’s because big stories, as a specific example of big batches, bring with them a number of risks.
We found that these big stories were indeed having negative impacts. These included:
So big stories were hurting us on three of the four success factors in the Agile framework that we use to manage risk: time, cost and quality.
Not completing work within a Sprint causes delays, and having unfinished stories blocking others makes this worse. Siloed knowledge of the codebase slows subsequent development. Delays cost our clients money, as time frames stretch out. When code review becomes difficult, the quality of code can fall. And all this can be compounded when developers are no longer passionate about their work.
One of the great things about working with this client is the collaborative way their Product Owners work. For example, they’re happy for the developers to write user stories. So the next time a big story was due to be brought into the Sprint, the developers looked to see if it could be broken down. Splitting stories is a powerful way of reducing batch size to manage risk.
This story was simple to describe. We just needed to move one service from the old version of the application to the new version. However, because of the scope of changes from old to new, the interconnections between elements, and the amount of legacy code, the story would be complex to execute.
The team found that the story could definitely be split. In fact, they were even able to split some of the resulting stories into smaller stories still. It was a practical example of the rule of thumb I describe in the my post on how to reduce batch size: To find the optimal size, make your batches as small as possible. Then halve them again.
Our developers found it challenging to split the story in a way that delivered value.
The way we achieved this was to tackle a single, vertical slice of functionality. We picked one high-priority element of the service and built everything needed for that: the data and data models, the logic, and the user interface. If we’d created the data, logic and UI for the entire service, we’d have gone many Sprints before delivering working software.
Choosing which story to work on first within a Sprint can also be challenging. In this case we started with the stories that reduced dependencies later. This helped eliminate the large number of stories we’d previously had blocked by big-but-unfinished stories.
This is related to another challenge. We needed to find a balance between intentional architecture and emergent design. We had to find the sweet spot between planned architectural choices and those that flow from what you learn by putting increments in front of your customers. In our case, we decided to put time and planning into building a solid base in the form of the data models and entities needed for later work.
Another challenge comes from having more stories in the Sprint as a result of breaking down a bigger one. This means we had to be disciplined and focus on pushing each one all the way through our workflow before starting the next one. You can’t consider a batch complete until it has been integrated or released. You can learn more about the benefits of limiting work in progress here.
One of the major benefits of reducing batch size is the concomitant increase in transparency, in itself a key way to manage risk. You can find out more about managing risk with Agile transparency here.
The discussions we had about how to split the story meant that the whole Scrum Team built up a more detailed understanding of what was involved. This understanding was enhanced as we discussed each story in our daily stand-ups. Progress was more transparent and the Product Owner had better visibility of the work.
Where previously we might have had a big story in which one developer had multiple tasks, now we have multiple stories which can be picked up by multiple developers. As a result, all the developers get to understand the full set of features, functionality and interdependencies. Everyone gets to escape their silos.
The increased transparency came through in the size of the stories. We sized the initial story as an 8. After the split, the total size of the resulting set of stories was 19. Our discussions had created a better understanding of the work involved, giving us more accurate estimates.
The benefits were particularly clear when it came time for code review. When one developer is ready to integrate a piece of work, they put it up to be checked by one of their peers. With the big stories we’d been working on, this sometimes meant that we were reviewing code containing more than 1000 changes. At this scale, it’s almost impossible to understand the intent of all the code. Transparency drops and the risk of low-quality code increases.
It’s a good example of the way risks from big batches manifest themselves when the batch moves from one stage in the workflow to the next. Big batches create bottlenecks.
When it comes to code review, this team is now working to limit any commit to 500 changes. We try to keep batches small at all stages of our workflows.
The high-priority element of the service has been integrated. The Product Owner can test it with customers and make sure it’s delivering what they need. And we can apply the learnings from this testing to the work to move the whole service to the new version of the application.
With big stories in the past, we’d finished Sprints without having anything to show at Review. We’d gone over time without delivering working software to our Product Owner. In contrast, having split up the story, we were able to give them a useful slice of functionality that’s delivering value.
Our developers are happier too. This is not just because they’re seeing the back of big-bang code reviews. It’s because they’re getting the sense of achievement that comes from seeing the fruits of their labours making a difference in the world.
| Guidance | Case studies & resources |
|---|---|
| Introduction to project risk management with Agile | Agile risk management checklist — check and tune your practice |
| Effective prioritisation | |
| Reduce software development risk with Agile prioritisation | Reducing risk with Agile prioritisation: IntuitionHQ case study |
| Increasing transparency | |
| How Agile transparency reduces project risk | Risk transparency: Smells, Meteors & Upgrades Board case study |
| Limiting work in progress | |
| Manage project risk by limiting work in progress | Reducing WIP to limit risk: Blocked stories case study |
| Reducing batch size | |
| How to reduce batch size in Agile software development | Reducing batch size to manage risk: Story splitting case study |
