Value Streams with Features and Epics
Our development backlog consists of a set of work items (including Stories, defects etc.). These are managed as an ordered backlog. They are typically large and more weakly defined when they are in the far future. They are continually updated by backlog refinement until they are rightsized at the top of the backlog and ready to be developed.
What are Value Stream Items?
The wider flow of value through the organisation is represented in a Value Stream, which is covered in a separate Play. What then are the items which flow in a Value Stream? Are they the same items as we see in the team’s backlog?
It is clear that a value stream will certainly include new product capabilities, which are the items which constitute customer value and will be on the team backlog to create.
The value stream also contains all of the other supporting work as we track both the creation of value and the introduction of “waste”. This includes defect fixes, technical debt reduction work. Remember that “waste” does not mean unnecessary work, just work which does not directly add value. Through the value stream, work goes into all of the items, and some of the items generate value.
However, a Value Stream Item is not just a Backlog Item.
It is helpful to track a value stream at a higher level of abstraction than a development backlog. A new idea is probably defined at a high level. At some point it will go onto the development backlog. It will still be relatively large and poorly defined. Through backlog refinement it will gain more definition until it is broken down into a set of rightsized backlog items.
We want to track each of these items through the whole value stream from idea to delivery. That means each needs to keep an identity even after the creation of smaller backlog items. A common mistake is that the original clear idea or concept is lost in the detail of the backlog.
If we decompose an idea into twenty Stories, we still want to track the idea. To avoid losing the overview, our value stream items function as containers for our detailed backlog items. We need to develop a hierarchy of some sort. At a simple level it will be:
- Value Stream(s)
- Value Stream Item(s)
- Backlog Item(s)
- Value Stream Item(s)
Features
There may be multiple value streams in the organization. Elements flow through the value stream. I have referred to these as “Value Stream Items” above in the same way as I refer to “Backlog Items”. There is no ideal and agreed alternative word for these. The value stream item will generate one or more items on the backlog which may be broken down further through backlog refinement.
It is useful to ensure the organization has a common language. “Value Stream Item” is manageable for all the items in the value stream. For the value-creating items on the value stream we need a word we can use a little more freely.
I tend to use the term “Feature” for these, although other terms can be used. The word “Feature” is generally well recognised outside development. A feature generally represents a trackable and reportable item of value. It can form the building blocks of reporting through the organisation. We can plan features to be the right size for communicating and tracking within the business and with customers.
A feature represents a trackable and reportable item of value.
What about Epics?
In Agile development you will often find the word “Epic” used for a related meaning. There is some history around the use of the word. The term “Epic” was chosen originally to represent a large backlog item.
Epic: An event or series of events … grand in scale or lengthy and arduous.
OXFORD ENGLISH DICTIONARY
If backlog items can be Stories, the word “Epic” simply means a large Story. The name was proposed by Mike Cohn in the early 2000s. Remember that backlog items will generally be introduced as fairly large and loosely defined will progress through backlog refinement.
“Epic” was intended to indicate a piece of work which had not yet been through backlog refinement and been rightsized so the team could work on it.
Features as containers
Remember that backlog items will typically start as large concepts and be slowly refined into multiple smaller deliverable items. In other words, an Epic was a product backlog item which did not satisfy the “definition of ready”. As the quote below says, it is too large (to be developed).
When a story is too large, it is sometimes referred to as an epic.
“User Stories Applied to Agile Software Development” – Mike Cohn
This is not exactly the concept I need for Features. An Epic was intended to be refined into multiple Backlog Items (Stories). As it is broken down, these Stories replace the original Epic.
To manage the value stream we instead want a long-running container which will contain multiple Backlog Items. We don’t want this to vanish once we have done the backlog refinement. Instead we want to keep using it for tracking. This allows us to manage the Feature from idea to delivery even though it will be refined as part of this process.
The ability to track our high level concept end to end is valuable. Because it’s useful, some tooling (notably Atlassian’s Jira) has implemented this container and (confusingly) called it an “Epic”. This is a substantially different use of the word from Mike Cohn’s original one, but as I’ve noted before, there are no standard terms in Agile…
Good practices
As part of agreeing organisational language, you should decide what you will call Value Stream Items. I prefer “Feature” for the name of a container, but if your tooling is based on using “Epic”, that is fine too. Choose what works for your organization and tools.
Features give you a useful tracking and reporting level so agree how the reporting will work. How does the organisation view the status of a feature as it progresses from idea to delivered item? What reports include feature data and in what format?
In the Plays on Scorecard we will look at metrics around tracking value.
Leave a Reply