In an earlier blog I wrote about the beauty of a user story and how in the agile world we capture product requirements in the form of user stories.
In fact, user stories are the most atomic elements of our work breakdown structure. In terms of sizing and detail, they sit at the bottom of this list:
- Themes - Large focus areas that may be aspirational and span the entire organisation. They will contain multiple Initiatives.
- Initiatives - Large bodies of work which are collections of Epics, and on their own have big objectives and can be broad.
- Epics - A grouping of Stories that cannot be completed in one sprint, but over several sprints.
- Stories - Short statements of requirements telling what is required from a perspective of an end user.
This structure is the ideal breakdown, but it can be adapted to whatever the team sees as working optimally for them. The reality is that many projects will tend to document the Epics and Stories, with the epics categorised by Initiatives.
What does this mean in practice?
When gathering agile requirements I've seen people enthusiastically launch into creating stories, grouped into epics which are usually just a single word category. Then its realised later that what they have actually documented is a mix of epics and stories.
A correction is then attempted and stories are broken down into smaller stories yet the original story remains. For these (top level) stories which were linked to an epic, it's realised that the story is actually an epic in itself and you can't link an epic to an epic. It all gets a little messy. Half the job of the scrum master though is to continually review and revise the backlog so that it is always clear and transparent to anyone.
Practice is often influenced by the tool that is being used as well. For JIRA users, some people will just break down the user story into tasks. The great thing about agile is that there is no single prescribed method. Rather, what needs to be followed is agile principles. The detail of how it is done is down to the team to decide and for this to be understood by everyone.
Slow down. Start with the epic
From my experience, its not unusual for the dev team to state epics when what they are trying to do is state the stories. Therefore it makes sense to initially consider documenting everything as an epic because this will more than likely break down into smaller pieces later. The epics will then naturally have some thing that connects them together and the initiative will then become apparent. If it turns out that the epic was in fact the user story, it can be moved to a story later.
The backlog structure of every project is a puzzle to begin with. The key is to continually review and revise this. At first this happens frequently and for sure, many stories and epics will be mislabeled but, take the time to get it right and eventually a sensible structure will take shape.