User Stories provide a powerful and succinct way of managing the individual requirements that a project is expected to deliver. The theory is that by taking an approach that centres on how a person might use a system in a particular way it will be easier to focus development teams on creating something that is useful, valuable and usable. Each story is meant to represent a small, self-contained piece of the puzzle that, when combined, create the big picture that everyone is supposed to work towards.
Keeping track of this bigger picture requires a higher level of abstractions. Stories that contain stories are called "Epics" and it is here that we can start to see a more strategic and programme oriented approach emerging. Yet there is still a fundamental weakness with the way in which Epics are used that can create problems for business teams working on long-term, strategic programmes. Put simply, they tend to be focused on just one component of the entire solution. An Epic may describe, for example, how a telesales agent is supposed to use a new CRM system to answer a customer's query, but it will rarely say anything about how the agent is supposed to be trained to use it, how the system will be configured, how a team leader will manage a team of agents or any of the other activities that must be considered when delivering a strategic programme.
From a purely IT perspective this may be entirely appropriate. The Epic should be concerned with something that can be delivered as a specific piece of value. As such a focus on how a member of staff might use a particular system may be the right thing to do. It may even be entirely appropriate for other Epics to be formed that do describe areas such as configuration, deployment, training, management and all the other business activities that surround a single deliverable. Yet from a wider organisational change perspective this fractured view is limiting as the complete picture of the impact that the new system will have on the whole business is not described, not understood and certainly not documented.
We therefore need to look for another level of abstraction. We need to bring together the various Epics that describe how our solution will evolve to its final endpoint, and how different functional teams and specialists will interact.
I call these Sagas.
This is more than a nice new term to describe an Epic of Epics. A Saga demands a more strategic mindset that is as concerned with the journey as the end state. Just as a Norse Saga will follow families over generations, so our Sagas will do the same. To this end they must have five characteristics:
- They are at the highest level of abstraction;
- They involve the many different families in the business, and explain how they are dependent and interdependent upon each other;
- They describe events in sequence and can span many releases, years or business cycles;
- They tend to evolve gradually over time; and
- Everyone can relate to a Saga and see their role within it.
Let's break these characteristics down and take a deeper look at each.
Abstraction
The Saga is the strategic vision. It sets out what the business is aiming for and charts the course for reaching it. Each and every thing done within a Strategic Scrum, Scrum of Scrums or Programme must be consistent with this vision and fit easily within the Saga's framework.
Families
Within a Saga it is entirely consistent to describe the same Epic more than one, but from the view of different families. In some of these Epics the event may be centre stage, in others it might be a peripheral event. Regardless of this, the Saga allows every person to see what their unique role is in the overall strategy and how they affect other people through their actions. In turn this allows functions such as HR, Sales, Marketing, Operations, Finance, typically excluded from direct reference in IT centric change programmes, to describe the impacts that the strategy will have on them.
Generations
Time - and lots of it - helps pace the Saga. Epics will typically span several weeks, whereas a Saga runs until it reaches it logical conclusion. As such the Saga provides a longer term view and a context, helping to align development efforts with strategy.
Evolution
How the strategy will unfold over time is another key component of the Saga. Rather like the major triumphs or battles, a strong Saga should explain where the major milestones are, what they will look like and who will be involved. This helps to give focus so that Epics can be seen within the context of how they advance the business towards its longer term goals.
Inclusion
Combining all of these elements together should create a sense of inclusion for the business. Individual teams may embark on their own Epics, but the point is that they should understand how that fits into the bigger picture, what has come before and what is likely to come.
Crafting a good Saga is a skill in its own right. The key, in my experience, is not to get bogged down in detail. This may sound counter intuitive given the size of the books that usually accompany them, but remember the origins of these tales. Many started in oral traditions, so they are often structured in a way that allows a novice to tell the entire tale relatively quickly, still retaining a sense of completeness, whilst the more experienced can dive into individual tales of heroism as they need.
In the same way a Saga should be constructed from the top down, creating the broad vista of the strategic vision, then populating individual Epic tales as project teams get to work. It could easily be the case that the Epics covering the deployment of the strategy over the next 12 months are clear and concise and detailed, whilst what happens three or four years from now is a little sketchy.
Rather than view a Saga as another way of describing a collection of Epics take a genuinely strategic viewpoint. Consider the Saga not as a means of describing a piece of functionality to be delivered now, but rather an expansive tale that explains how, over the next few years, the business strategy is going to unfold and how everyone will play their part.
Share on LinkedIn
Share on Twitter
10