Size Does Matter – even when you’re Agile

Hi fellows,

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.

Fruit Bowl

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.

Shakesgrear-120108-DSC_7491

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?

PacLease - Liberty Fruit T800 1

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.

Day

Even per day we do plan in Agile. You might have hear of one activity that is called the Daily Standup. In other flavours of Agile planning might even be done several times per day for example in Kanban when you focus on keeping the work in progress limit low and ship fast.

It’s all in how you size it

Have a look at the picture to understand the different artefacts of planning, their sizes and names.
This is not an official list and most of the names besides Story are often confused and used where they don’t belong.
But how does this relate to the 5 levels of Planning?!
What names to use in which context?

Rules of Thumb for Sizes

Below you can find the rules that I use when working with teams.
If you can and should use all of these in your working context totally depends on the environment  that you work in.
If you only have one team and no long term business objectives you could also only need Features and Stories. Some teams don’t break down Stories to Tasks, because their PO slices the Stories small enough to be implemented in 1-3 days.
When you work in an area where you need to do Portfolio Planning it is rather important to not confuse the different sizes of work items.
In Vision and Roadmap Planning often only the terms Feature, Epic and Theme are used.
This is done to hide the big complexity of having hundreds of Stories and to keep a good overview.
When you do Release Planning, you want to know when you get Features A, B and C, but you’re not interested about the Tasks that the team breaks out of the Stories.

A Story might be a Feature but not an Epic

Features and Epics for some people are the same. I like to distinguish them.
The format to describe any work item in Agile can be exactly the same: “AS A…, I WANT TO…, SO THAT…”. This makes it so hard to differentiate. This is why I like to use different coloured Post-It’s to signal what is a Story and what a Feature or Epic.
While discussing about a Story you might find out that it is too big to fit in a Sprint and therefore is a Feature, then you break it down into several Stories which you can then implement Sprint by Sprint.
One example for an Epic would be: “Implement checkout for a WebShop”.
This would break down into Features like “Choose payment possibility, provide delivery address, show confirmation page”.
Stories could be “Add paypal payment, credit card payment, invoice payment”.

What does all of that have to do with fruit?

So why on earth did I start talking about 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.

[53/365] ● fresh and tasty

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

Leave a Reply

Your email address will not be published. Required fields are marked *