Sagas: Bringing Life to the Strategic Vision

6 December 2011

Ross Hall
Dalmeny Close

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:

  1. They are at the highest level of abstraction;
  2. They involve the many different families in the business, and explain how they are dependent and interdependent upon each other;
  3. They describe events in sequence and can span many releases, years or business cycles;
  4. They tend to evolve gradually over time; and
  5. 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.                                                                      

Article Rating

Current rating: 0 (0 ratings)

Comments

Joe Morgan, CSM, 12/6/2011 7:00:39 AM
Ross, interesting article. We have been delivering value add to eight independant client groups utilising a configurable project management product within our organisation. We've been practising SCRUM for 2 years now. We were, like a lot of fledgling SCRUM teams, challenged during the transition, but have been seeing real value for approx 18months now. As SCRUM prescribes, each sprint brings the opportunity to learn & adapt. Our current implementation and execution practise is now well tuned and has brought real & tangible morale and delivery improvements.
We did hit concerns with a particular client group in early 2011 who were well advanced in a significant initiative, spanning up to six sprints. We developed numerous user stroies and were efficient in the process of breaking the activity into workable tasks. The client concern came from the fact they lost their view into the bigger picture as the initiative progressed; and during a retrospective explained they may have done some things differently had the bigger picture remained in focus. Do you have any template or examples of Saga's with their associated Epic's and User Stories? I'd be interested in seeing a good example as a guideline for future reference.
Michele Cresmen, CSM, 12/6/2011 2:55:45 PM
I'd be interested in examples too!
Irene Michlin, CSP,CSM, 12/7/2011 11:29:25 AM
Have you been reading "Game of Thrones", by any chance? :-)

Seriously, what's the difference between this and traditional "roadmap" of waterfall projects?
Nguyen Doan Nguyen Vu, CSM, 12/11/2011 9:25:45 PM
Very interesting Saga explanation.
Jeremy Shaw, CSM,CSPO, 12/12/2011 7:34:40 PM
Thanks, Ross - interesting article. I'd like to add my voice to the chorus asking for a concrete example! :-)

I wonder whether a Saga would be a good way to address the common concern I've heard which is around establishing a software architecture vision? The usual answers such as "investigation sprint" or "prototyping sprint" or some such don't feel to answer the concern quite as well as I'd like. The time dimension of a saga could be what I'm looking for.
Andreea TOMOIAGA, CSM, 12/13/2011 9:45:08 AM
Hi Ross, in my opinion the article was interesting. I am asking myself if you see a connection between Saga(s) and a classical feasibility study comprised of

Cover sheet
Executive summary
Table of contents
Descriptions of product/services
Descriptions of roles & responsibilities
Definition of technology used
Business Model
Marketing strategies
Critical risk factors
Financial projections
Conclusions
Ross Hall, CSM, 12/13/2011 2:35:37 PM
Thanks to those asking for examples - I'm pulling together a couple of anonymous examples that I'll post a link to here in the next couple of days.

-- Some specific replies --

@Irene, no but the origins are in Norse sagas. As for roadmaps, I've found they tend to be highly IT oriented and assume a solution that then becomes difficult to unwind when the world changes. The story telling nature of a saga continues the philosophy of evolving and adapting to change more effectively IMHE.

-- @ Jeremy It is possible. It should make the business level requirements much clearer. Sagas are likely to start pre-Sprint though as they'll drop out of the visioning and strategy component before budget and resource commitments are made. Should be possible to refine them in the "minus" sprints though.

-- @Andreea That's a format question. IMHE the key with all of Scrum is to find a format that matches to the business that's sponsoring the activity. If a formal feasibility presentation works for you then it can be made to work.


Anantha Narayanan, CSP,CSPO, 12/17/2011 11:19:13 AM
I like the idea of Saga but will agree to @Irene comment about its similarity to road-maps of WF projects.

The granularity of user stories is a continuous challenge in Scrum Framework. The problem that a story writer always faces when putting the details of the story down is, "how much is sufficient?"

My only concern with the Saga is the introduction of one more layer to the frame work. The example in the post looked more like dealing with tactical issues of the system involved and strategy looked as an effect out of it.

My suggestion would be to fall back on tried on true User Story format to write your use cases for these tactical issues on how the training module will function, how help desk need to work etc?.

I employ Use Cases, Themes and a visible Road Map to deal with 50,000 feet issues.
Aaron Steele, CSM, 1/14/2012 4:07:47 PM
Interesting concept, but I, as with the others, would have some questions around the full implementation. I tend to see scrum (and admit I haven't been doing it too long) as a fantastic tactical framework, but it is lacking when it comes to long term strategy. Personally, I don't have an issue with that and would be satisfied using it simply in that vein, but when people try to use scrum in a strategic sense, it seems to make more issues and actually weakens its tactical usefulness. But again, I would be very interested in seeing a example solution. Thanks.
Christian Macedo, CSM, 3/27/2012 5:34:21 AM
Ross,

Great article especially on a little discussed idea, whether it be in the form of Sagas or otherwise.

You put forward that the Saga offers a higher strategic view of any given project and this is certainly something that I've seen a lot of higher management absolutely need. In addition to that the implementation of Sagas provide, as you mentioned, good milestones against which it's easy to see how far in the vision the team are.

The issue here is not what can we implement to be able to offer a strategic vision, but rather what is there about Scrum that people need to understand to see it already offers the potential of a strategic vision.

We already have at our disposal, tasks, stories and epics, which in turn fit into sprints, releases and ultimately projects. The granularity is pretty fine if required, and so a release could in fact be just one milestone in the Saga you're looking for.

The other consideration is, do we have the tools to handle this? Let's take one of the more popular tools out there, Jira. It has a host of abilities, and if you're good at Crystal reports, you can get a view up and running which reflects the Saga perfectly.

In short, I like the idea, and there is huge merit in being able to have a Saga so that strategic vision is preserved for everyone at all levels in the organisation. And I would add to that: Why create more process when we can already obtain that high level view? And, Is Scrum there for tactics as well as strategy?


You must Login or Signup to comment.