rocket We’ve joined the Appfire family! Learn more
Jun 18

Stories, Initiatives, and Epics Across Agile Frameworks

Initiative epic story

Initiatives, epics, and stories belong to the agile realm. From here the surprises begin. It turns out that the popular Initiative – Epic – Story hierarchy is not engraved in stone. Scrum, Kanban, SAFe, and LeSS approach initiatives, epics, and stories differently. It is the “living backlog”, rather than epics and stories, that streamlines the product development process and the epic and story labels were invented to reflect the client-centricity of that backlog.

The initiatives, epics, and stories are not limited to software development. Banking, commerce, marketing, leisure businesses benefit from the client-centric agility the three terms entail.

We will start with four industry-specific examples of initiatives – epics – stories triad. Then we will break the three terms into pieces. We will finish with how BigPicture leaves Jira – which is brilliant for task management – behind in terms of how initiatives, epics, and stories can reinforce your product/project management.

Initiatives, epics, and stories by industry

Let’s move on to the examples. How are initiatives, epics, and stories different from the proven tasks? Does the ‘as a user, I want… so that…’ formula make the magic happen? The answer is no. It is the agile “living backlog” approach that works miracles. The living backlog means that a recently created epic can outrival an older one in a race to the finish line if the former is expected to deliver more business value.

Table 1: Initiatives, epics, stories examples by industry

Industry Initiative Epic User story
Approximate duration Several months to a year to complete. Epics are to be just manageable (the right number of stories in an epic). One sprint.
Banking /
Software development
Mobile banking Checking account

Savings account

Company account

As a customer, I want to check my account balance, so that overdrafts don’t happen.
Marketing Product launch campaign Internet campaign,

Tv campaign,

Print media advertising

Design Internet ads,

Create a TV advert

Media planning

Retail Introduce regional products to a supermarket chain Cheeses range.

Smoked meats range,

Deli range

Find suppliers,

Verify quality,

Test-launch new assortment at selected locations

Tourism, travel agency Set foot in Australia Select hotels,

Hire guides,

Obtain licenses

Research hotels in Victoria,

Research hotels in Tasmania,

Interview candidates by state

Can managers depart from the standard ‘initiative – epic – story’ hierarchy?

The seemingly engraved-in-stone initiative – epic – story hierarchy is not as fixed as one might think. Scrum, Kanban, SAFe, or LeSS obey that commonly seen hierarchy to various degrees.

Scrum.org says that Product Backlog is an emergent, ordered list of what is needed to improve the product. While Scrum practitioners mostly use initiatives, epics, and stories, all that the model backlog at scrum.org displays are ‘Requirement’-labeled bars.

Scrum board BigPicture

 

Kanban is a foundation and not a strict framework. Many Kanban boards see epics, user stories, and initiatives. The focus, however, is on column titles – To do – In progress – Done – and on limiting the work in progress. Hence many Kanban boards contain tasks of no particular type. Whether a piece of work is a user story or an epic is secondary in Kanban.

Kanban board BigPicture

 

SAFe has epics but they sit at a higher level than with most other project management methodologies. Features, and not user stories, sit one level lower than epics in SAFe.

Epics in SAFe. Features instead of user stories

 

LeSS.works states that a good Product Backlog must:

  • have estimates for all items,
  • have finer-grained items at the top and coarser-grained items further down, and
  • be prioritized

Of all four, SAFe is the only stringent and prescriptive framework as far as the backlog structure is concerned. Features and not stories or epics are in the spotlight here, though.

All in all, the seemingly standard initiative – epic – story hierarchy is an option or a good practice rather than a norm. Consider initiative – epic – story hierarchy a good starting point for designing your custom management framework.

Why the odd ‘Epic’ and ‘Story’ names?

Are the ‘Epic’ and ‘Story’ labels pure marketing? Or do they have some intrinsic yet hidden value? These peculiar names are not an accident. They bring two things to the table:

  • client-centricity
  • specific uses of the product (‘as a user, I want… so that…’)

as opposed to traditional tasks that get scheduled and must meet deadlines.

Top-down or bottom-up planning?

Let’s move on to the process of planning. When planning and scheduling, should you begin with initiatives, only to break them down into epics, and then to stories? Or should you do it the other way round – begin with fine user stories and then group them into higher-level epics and initiatives for manageability?

‘Living backlog’ is the answer again.

Sure, great ventures lift off as an effect of top-down planning. You break initiatives into smaller epics, and epics into stories.

However, once the project or product gains traction the bottom-up planning should take over. Once your product hits the market, and users begin to request fixes and improvements, you gradually add new user stories to the backlog, effectively doing the bottom-up planning. The bottom-up direction is also how epics get estimated when they would be completed (when the last of an epic’s stories is completed). Bottom-up is also how the public roadmap gets updated – the aggregated user stories “output” the date a given epic should get completed.

How to track the progress of stories, epics, and initiatives?

Tracking progress is where we seamlessly move on to BigPicture. Remember how we said that BigPicture can put initiatives, epics, and stories to work in a way that Jira alone cannot? Figures 5 and 6 showcase modules of BigPicture, a PPM app for Jira. The modules do a great job of aggregating stories and epics. Pay attention to the ‘Status’ and ‘Story points’ columns. BigPicture can produce the big picture for an agile, product-ridden organization.

Gantt / Roadmap of BigPicture. Epics and stories

Figure 5. Gantt module of BigPicture was relabeled to ‘Roadmap’ for the purposes of this agile project. Note how user stories get aggregated at the epic level. Sum/Count/Avg/Mix/Max functions can be employed at the initiative level, too.

 

Board with backlog. Epics, stories and initiatives

Figure 6. Board with the backlog in BigPicture. Epics, stories, and an initiative that you can see in the backlog are all Jira issues. You can add your own entities in BigPicture (phases, milestones, Program Increments, etc.) on top of the types available in Jira.

Structure builders available in BigPicture Box configuration let you design the work breakdown structure (figures 2 and 3) to your liking. For instance, you could add sub-tasks as the fourth, lowest level of the tree, or exclude initiatives from the hierarchy altogether.

Roles

A word on roles.

Product Owner and Product Manager own initiatives, epics, and stories.

Product engineers, software developers receive stories and get the things done.

Stakeholders focus on epics and initiatives and direct their attention to Overview, Roadmap, and Reports modules of BigPicture.

 

About The Author

With his automotive background Marcin goes beyond the 'Jira + software development' standard. He likes simple, up-to-five-sentence answers to complex questions.