Stories, Initiatives, and Epics Across Agile Frameworks

[#1]

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

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

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.

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.

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.

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.

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.