Agile Forest

Do you know what the difference is between an epic, a theme, a user story, a feature and a MMF is? 

I am willing to stand up and say that I have no idea anymore. I have just spent over an hour looking over books, presentations and blogs to try and find the answer and the result – there is no consistent answer!

Is it any wonder that myself and my peers regularly disagree on the decomposition of these when the community itself at large seems to contradict itself so much?

Lets start with the most academic stance. Mike Cohn, writer of the book User Stories Applied and Agile Estimating and Planning. If a clear stance is to be found it would be here.

Mike writes (slide 19) that the decomposition is Epic -> Theme -> User Story. It’s a pyramid. It’s pretty damn clear.

Then you can go to any dozen blogs that argue that it is Theme -> Epic -> User Story.

The mystery deepens when you add in Features and Minimal Marketable Features. Then it grows even further with the advent of Lean using Minimum Viable Product (MVP), Minimum Viable Feature (MVF) or Minimum Marketable Release (MMR) instead of MMF.

There are tonnes of blogs, most saying that MMFs are actually an alternate to Epics; others say that it goes MMF -> Epic and then the third variant is Epic -> MMF. If you add Themes back into the equation it just becomes a big pile of… umm… confusing stuff. Then there is the ‘Are all features MMF’s?’ debate. Is one a subset or a grouping of the other.

Oh and on top of that we see the Kanban community using ‘goal’ and ‘objective’ and starting saying things like
Goal -> Objective -> Epic -> MMF -> Story -> Task.

Then we have some calling them Story and others User Story.

IS IT ANY WONDER WE ARE CONFUSED? 

Just as the ideal size of a User Story has changed over the years it seems that the way in which we decompose a Story has also changed (probably as a result of the ideal story size change and consequently having to split them down).

Have you ever tried to speak to a Product Owner and try to explain these weird terms to them. They look at you as if you are from Mars; and I feel rightly so.

Instead of confusing them with terms like ‘Epic’, ‘MMF’ and ‘Story’ this is the parable I tell them:

We are going to look at your problem that you approached us with. We are then going to spend some time understanding all of the related problems and find the root cause. Then we are going to discuss your high level needs and break then down, bit by bit until they reach a size that we feel we could build to in around three days (and link them back to the root causes).

We don’t have to build the whole high level need at once. We can do it bit by bit ensuring that the stuff (technical term) that we build is worth the most value. When you think you have enough stuff to push out to the end user then we will release it even if the complete high level need has not yet been fully realised.

If this all doesn’t make sense then think of it in terms of a library.

I then tailor the library description to the depth of the project they are working on – ie it might be a program or a project with many phases, it really doesn’t matter, what matters is that the size is ever decreasing:

Library -> [Categories] -> [Series] -> Book -> [Part] -> Chapter -> Paragraph -> Sentence -> Word

A release is a book because more commonly than not  you cannot sell a chapter or a paragraph, but you can sell a book or a series.

An organisation’s portfolio would normally be the library.

The story for me is the sentence. You can test a sentence, test that grammatically it fits together, but additionally you can test the components within it (words) for errors (spelling mistakes).

I realise that I am probably going to make the confusion even worse by putting this out there, but until there is a bit more clarification from the heresiarchs then I am sticking with this.

UPDATE: Subsequent to when this post was written Mike Cohn and Kent Back came out and clarified their personal stance of Feature -> Epic -> Story from a decompositional perspective. I would say as a community we should try to follow this lead and see if it over time solves some of the confusion.