That old chestnut “size matters” applies just as much to Agile as anything else.
We’re all already used to the idea that user stories are small things and epics are big things. But just how small and just how big?
Read on and I’ll tell you…
The subtle difference between sizing stories and estimating them
Planning poker is fun (or it should be): discussing a user story, its acceptance criteria and how it will be built and then estimating, wondering whether the team is in tune with one another at judging whether something will be simple to build or more meaty. The cheers and groans when everyone’s guesses are revealed.
But that’s merely labelling up work that already exists. Sizing, defining where one self-contained piece of work stops & the next starts, happens way before that, when the Business Analyst first decides whether New Function A can be written in three user stories or thirty. Get it wrong and the effects trickle on through the rest of the work, making everything harder to manage and deliver. At the very least, poor sizing causes extra work to re-draft the stories correctly.
Why sizing user stories correctly matters
Just like Goldilocks, there’s an optimum size that’s just right for your team: small enough that they’re able to close stories quickly and benefit from the feeling of momentum. And large enough so that they’re not wasting time updating a million tickets. There’s a size range that’s ‘just right’.
Size matters for epics too
Why do we even gather work into features & epics? Because it’s hard to juggle and schedule a million individual stories. But group them together into sets and they instantly become easier to organise.
But grouping a thousand stories into a handful of epics doesn’t help us much:
- choices for stack ranking the five epics is limited, restricting our ability to apply meaningful scheduling
- nor does it ease the burden of sorting between stories within an individual epic: 200 is still far too many to juggle easily
Add an extra layer, say features, and each layer might only have 20 things to think about at once – much more manageable!
So, before anything else, first choose your grouping levels: is it a small project where a simple structure of epics & stories is enough? Or is it a more complex programme of work that needs a multi-layered approach?
My tried and tested flexible rules of thumb for sizing work
We’ve seen how teams differ in velocity. And we know that work varies in complexity. It should be obvious that creating hard & fast rules about sizing is nigh on impossible.
Over the years I’ve developed some guidelines that blend absolute and contextual approaches together to make a practical set of rules of thumb that anyone can apply to any team.
I’ll use the common structure of Epics, Features, User Stories and Tasks, but the rules can be applied to any structure.
Rule of three: easy rule of thumb for deciding whether work should be a Task, a User Story, a Feature or an Epic
The core rule is based on how long your team would typically take to complete the work.
The ideal length of a work item should be 1-3 units… and the units help you decide what it is:
- 1-3 hours, it’s probably a Task
- 1-3 days, it’s probably a User Story
- 1-3 sprints, it’s probably a Feature
- anything longer, it’s an Epic
You can also use the rule the other way around too: if you know something needs to be a User Story but it feels like it might take weeks to do, you can quickly see that you need to split it into two or more stories.
Rule of fives: advanced rule for structuring & sizing work in your backlog
The guidelines above give a basic breakdown. But work complexity comes into it too. Just as a company won’t thrive with if there are too many or too few managers, the best backlogs have a good balance between too many or too few work items under a parent.
There will be exceptions, but the rule of fives is a good starting point:
- 5-10 Tasks in a User Story
- 5-15 User Stories in a Feature
- 5-20 Features in an Epic
Why aren’t they consistent, I hear you ask? Because delivering the work (Tasks & User Stories) needs small chunks of detail & focus, and managing the work (Features & Epics) needs bigger chunks and the simplicity that that brings. simplicity
Got questions or guidelines of your own? Grab me for a quick cuppa