Structuring the Agile backlog

Dec 18, 2019

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.

Shall we talk?

Lets have a conversation

If you would like to know more about how I've helped to transform some the world's biggest and well known businesses, across diverse industries in the United Kingdom, Singapore, and Hong Kong, then please drop me a line. Let's have a chat and I'll buy the coffee!

Multiple screens showing responsive web developement next to a hot drink for a meeting

Turn your idea into digital reality

Many of my clients requiring web design have been small or start up businesses and need a lot of guidance. I love these kind of projects as I feel I can be a part of a new and exciting business from the very beginning!

What can I call you?
Enter your email address
It would be nice to tell us why you are contacting us!
To prevent spam mail, enter the sum of the spam captcha