during the past years when I worked with teams or organisations I often noticed that defining the size of requirements is something that many have problems with.
Now before I start talking about the world of Software let’s use a quite simple example.
Getting Food. And to keep it simple we only use fruits now.
The fruit exercise
If you need to get food for one person things should be quite clear.
You’ll get one apple, a banana some cherries or grapes and you’ll be set.
Would you buy 3 Water-Melons for a single person? Rather not.
To feed a single family you’ll need a bit more. So you’ll go for a big Melon, a bunch of bananas, bunch of apples some oranges and then you’re done.
Now if you throw a big party for all generations of your family from Grandpa until grandchildren?
You’d no longer think of single apples but count in crates.
Let’s think bigger. You’re organising a big party in your sports club and assume that 500-700 people are coming, it’ in 2-3 months. What would you buy? Do you have any empirical data to know what you’d need there? Difficult, right?
Enough of fruits. We’ll come back to that later.
Even in Agile Software development you do plan.
And there are distinct levels of planning.
5 Levels of Planning in Agile
Vision (1-3 years)
The vision is the reason why we are developing the next version of our current product(s). It gives guidance to all parts of the portfolio for long term alignment.
Roadmap – Portfolio (1/2 – 1 year)
Depending on the size of your company you might have a full portfolio of different products. Some of them might have dependencies between each other. Portfolio planning depends on the release cadence but is usually done less often than release planning.
Release (several per year)
The long term goal comes along with certain key elements that have to be created in order to achieve the goal. Those elements are analysed and broken down to be implemented in releases. I’ll explain what does elements are and how we call them in agile in a moment.
Sprint (1-4 weeks)
A sprint defines the amount of work that a cross functional team can do in the sprint cadence. Scrum teams usually use 2 weeks but the range is from 1-4 weeks.
It’s all in how you size it
Rules of Thumb for Sizes
A Story might be a Feature but not an Epic
What does all of that have to do with fruit?
Well, food for people is a concept that is much easier to grasp than sizes of requirements in Software development.
While it’s totally easy for you to define how much fruit you’ll need for one person it’s already a good bit more complex to find the right amount of work to do for one day or to correctly size a Task.To find the right amount of Stories for a Sprint is already even much harder compared to feed a full family with fruit.
When you think of organising a big party for 500-700 persons would you think in Single Apples, or bowls? Or would you rather directly buy crates?
This is the same in Planning Releases. You don’t talk about Tasks or Stories. You want to have Features/Epics done.
When you start with a long-term (2-3 years) vision. What do you do first?
No clue? Well you might start with breaking things down to sizes that you can handle like Themes and Epics prioritise them based on criticality, business value, cost of delay and put them in a flow.
And then you start defining the first Release where you break down Epics to Features and Features to Stories. From there on you do that continuously Release after Release adjusting your Roadmap as you go and reflecting the market situation and the constantly changing requirements.
I hope this gave you some insights into how work items are sized when you use Scrum.
Next time you talk about work items you know which term to use when.
And if you talk with someone that doesn’t get it point them here so they can read about it.
Don’t mix apples with pears 😉 or Stories with Tasks/Features
If any of the concepts explained here doesn’t make sense or you use the terminology completely different leave me a comment or Tweet. @MrSnow76
Thx for reading,
Sven aka MrSnow76