Monthly Archives: October 2014

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

4 days ago my Ex-company lost a great guy.

 

Let me tell you the story of him.

Almost two years ago he joined the company. Fresh, full of energy ready to change the world.
He’s a passionate guy, motivated, willing to learn.
He joined the company because he could identify with it, the Mission the values everything seemed to fit perfectly. And he wanted to learn from the great experience that others had aquired before him so he could grow and get better while working with people.

To give you a bit better understanding about the backgrounds of his decision to leave the company let me quickly introduce to you the 10 intrinsic motivators that have been called CHAMPFROGS by Jurgen Appelo.

Intrinsic Motivators

Curiosity
Honor
Autonomy
Mastery
Power
Freedom
Relatedness
Order
Goal
Status

His personal Motivators in priority order

1. Mastery -> Honor -> Curiosity -> Goal -> Relatedness -> Freedom -> Autonomy -> Power -> Order -> 10. Status

As an Scrum Master/Agile Coach in an ever-changing world it is incredibly important for him to stay up to date with the latest and greatest, this is why Mastery is the most important for him.
Honor in the form of being honest and open with the people he works with is one of his key personal values and non-negotiable like quality in Agile Software development.
Curiosity is the driver for Mastery, without it no continuous improvement.
Working without having a Goal is like trying to reach a Mountaintop without choosing the right path beforehand. It might get you there but is highly unrealistic.
Relatedness is extremely important for someone who works with people. If the way of how a Coach works and the content provided doesn’t fit the audience then it doesn’t matter how competent one is in terms of Mastery.
Freedom is one of the core values of Scrum and the agile way of working. Self-organisation is the expression of that. Thus it’s important for someone working agile.
Autonomy is closely related with freedom but should be a given in an agile environment.
Power is not that important, although being respected and heard is important as a Scrum Master or Agile Coach.
Order is a temporary illusion in an ever changing world.
Status in the end is the last important thing for him since leadership is always the result of the right behaviour and not the position in the hierarchy.

Why he couldn’t stay

Mastery – growing the individual was somehow supported but only on a personal level, not organisation wide
Honor – Being completely open and honest was not possible due to hierarchical structures and the lack of feedback mechanisms
Curiosity – He couldn’t do the things interesting for him since he always had to jump in where the fire in the company was burning highest
Goal – Even though goals were defined together with his superiors he still wasn’t able to achieve any of them since the companies needs were put before the individuals goals
Relatedness – this one was fulfilled since he got good feedback from the teams he was working with
Autonomy – Since he was mostly told what to do it was difficult to get things going. Often new ideas and improvements were actively blocked by management.
Power – the feedback he gave was rarely heard. So it was hard to improve anything
Order – the given order was pushed on everything that had to be done, even if it might have not been the right thing to do. He hated that.
Status – Even though his status rised while working in the company due to the good feedback, he still didn’t care since he couldn’t really achieve what he came for

So why did I share all of that with you?
Isn’t money and status a big enough motivator to keep knowledge workers happy?
As you can see in the example above, it is not that easy depending on the values and needs of each individual.

If you wonder who the guy was… it’s me. (don’t worry, I don’ think I’m great but it sounds better as introduction, no? 😉

I’d be interested to hear from your own experience how companies can do better in motivating people and also what you think about the CHAMPFROGS approach to define the intrinsic motivators.
Please leave a comment or contact me on google+ or @MrSnow76.

Thx for reading,
Sven Schnee aka MrSnow76