Initiatives, Epics, Stories, and Tasks: The Allstacks Way

Over at Allstacks, we’ve seen hundreds of ways of structuring work for your teams. Some ways work well, and others, well…  We won’t talk about them.  Part of our core philosophy is that by aligning business goals and day-to-day engineering work, you both empower teams to directly add to the bottom line, while also helping leaders clearly see the ROI for their engineering orgs and teams.  It’s no surprise that leadership looks to planning and project management tools like Jira, ADO, and Shortcut for making sure that everyone is pointed in the same direction.

These tools do a lot.  From helping run standups, to facilitating roadmap planning, to breaking down work, they often serve many teams and roles.  However, the most important aspect of these platforms for bridging the gap between company goals and individuals day-to-day work is the ticket hierarchy used.  While different teams may work in different styles, the company view of if initiatives are delivered is often singular.  That’s why it’s important to build a great structure that empowers each team to approach their portion of the work in the way that works best for them, while also properly reporting status and focus to leadership.

From our broad experience, we’ve typically seen success when companies use the following structure.

The structure

We typically recommend a 4 level hierarchy: Initiatives, Epics, Stories, and Tasks.  Each level follows a different process because it serves a different role in the organization.  Let’s go into detail on each of these pieces.

Initiatives

Who it serves: Initiatives serve senior leadership, providing a strategic overview that aligns with the company’s broader business objectives. These high-level goals are crucial for ensuring that all efforts across the organization contribute to the company’s vision and long-term plans.  Initiatives often guide the work of multiple teams or whole departments for a quarter or longer.

How is it scoped: Initiatives are scoped at the macro level. They define the overall direction and goals but leave room for flexibility in how those goals will be achieved. The scope should be broad enough to encompass various departments and teams while specific enough to guide the creation of epics and stories that will drive the work forward.

What is its workflow: Initiatives typically start as ideas or goals identified at quarterly or annual planning meetings by senior leadership.  They will often be developed the quarter before work actually begins, and will involve a lot of planning from the product team in the lead up to development kickoff.

How is it estimated: As initiatives tend to span multiple teams and even multiple quarters, estimates are typically at a high level and provided by senior product managers and staff engineers or architects.  Estimates typically take the form of a number of people or teams times the amount of time it will take them.

Notes: There are typically two types of initiatives, Evergreen and goal based.  All of your teams’ work should be driven by an initiative with a defined business goal.  Evergreen goals are often things like “Don’t have p2 bugs” or “Ensure 5 9’s of uptime”, and are still able to properly serve teams that don’t typically work on the quarterly product roadmap goals.

Epics

Who it serves: Epics serve product managers and team leads, acting as the bridge between high-level strategic objectives and the detailed work carried out by teams. Epics break down initiatives into more actionable goals that teams can focus on over a series of sprints, often spanning multiple weeks or months. They ensure that the work aligns with the company’s broader objectives while providing clear direction to the teams involved.

How is it scoped: Epics are scoped to address significant portions of an initiative, translating the broader goals into specific, measurable outcomes. The scope of an epic should be well-defined to ensure that it can be completed within a reasonable timeframe, no more than several sprints. It should be specific enough to guide the creation of stories but flexible enough to allow teams to adapt to changing requirements. There should be an expectation that epics result in a significant release or product announcement into production, and not simply arbitrary breaks in the work.

What is its workflow: Epics begin being scoped near the end of initiative planning.  Senior engineers and product leaders will typically take the high level goals and work to define value creating releases that represent roughly equal amounts of development effort.  This typically happens in the quarter or month before the work is scheduled to begin, with product research happening ahead of and directly informing the engineering estimation work.  Epics should generally be owned by a single team, with dependencies between teams and domains being handled with proper epic scheduling.  Once started, epics should be worked until completion, as they are defined to deliver significant value when completed.

How is it estimated: Estimates for epics are typically provided by product managers and the team responsible. These estimates are usually higher level than those for stories, as epics can span multiple sprints. Since epics should be able to be completed by a team without any outside dependencies, a team should be able to provide an estimate in a number of sprints required for the team to complete, taking average capacity into account.

Notes: Epics are critical for breaking down the large, seemingly insurmountable goals of an initiative.  Where an initiative may define an outcome based goal, like “Increase sales of Package C”, each initiative should define the experiments we’re making to attempt to achieve that goal, like “Deliver a new report that does X”.  Because of this, Epics represent the central agility in your organization by providing for specific experiments that when complete, we’re able to check if we’ve met the initiative’s goal.

Stories

Who it serves: Stories serve individual contributors and their immediate teams by breaking down epics into specific, actionable tasks. They provide a clear description of what needs to be done and why, helping team members understand how their work contributes to the larger goals. Stories should be completed within a single sprint [or a specified cycle time if you’re using a flow-based process].

How is it scoped: Stories are scoped narrowly to be completed within a single sprint or iteration. Each story should be small enough to allow for quick development, testing, and feedback, yet should deliver a meaningful increment. There should be clear acceptance criteria defined, and development should meet the team’s shared definition of done and other non-functional requirements.

What is its workflow: Stories are typically created during sprint planning, where they are prioritized and assigned to team members. The workflow for a story follows the standard Agile process: it is added to the backlog, prioritized, and then worked on by the team. Once completed, it is reviewed against the acceptance criteria, tested, and either deployed or moved to the next stage of the process.

How is it estimated: Story estimates are usually provided by the team during sprint planning. Estimation techniques like story points or t-shirt sizing are often used to gauge the complexity and effort required. The focus is on ensuring that the story can be completed within the sprint, allowing the team to maintain a steady pace of progress and understand how many sprints out the parent epic is trending.

Notes: The story level will actually represent multiple types of work each with slightly different process patterns.  Bugs, Spikes, Customer Requests, and many other types may show up here in your process, each with slightly different responses from the team.  The guidelines here represent how all of those should behave, while leaving wiggle room for relative priority and varying team response to each.

Tasks

Who it serves: Tasks serve developers, QA engineers, and other individual contributors by breaking stories down into the smallest units of work. Tasks are the actionable steps that must be taken to complete a story, providing clear guidance on what needs to be done next. They are typically small enough to be completed in less than a day, keeping work focused and manageable.  Tasks should help the individuals on the team coordinate completion of the story within the sprint

How is it scoped: Tasks should be defined in refinement or estimation by the team during sprint prep.  Tasks should be created by the individual team members as part of the estimation process to facilitate accurate estimates and help the teams develop their plan of attack during the sprint to support parallelization.

What is its workflow: The workflow for tasks are fairly straightforward.  An individual picks up a task, completes it, and moves to the next task.  This can be a little flexible as tasks serve more as checklist of things to be done that a prescriptive order

How is it estimated: Tasks are not estimated, but instead are used to build a good estimate for the story.  Tasks should always be assumed to be less than a day.  Anything larger should be broken down.

Conclusion

Software organizations represent a huge investment by the company into the future of the product.  Without the proper links from the individual developers to the business goals, it’s easy for the vision to get muddled or lost.  When that happens everyone ends up frustrated at each other and progress grinds to a halt.  Even in an organization with great culture and well-intentioned people on all sides, this type of process issue can have detrimental effects.  

This structure is based on synthesizing multiple successful organizations' processes into guidelines that work regardless of tools or process, and some areas, like “quarterly planning” aren’t explicitly defined here.  This framework allows for flexibility and customization based on the business needs while still providing the structure and framework that breeds success, visibility and alignment.  Go build great software!