Once a software team leaves the familiarity of waterfall or other traditional project management styles they often feel the pain of "how do I structure my work?" Fortunately, agile development uses four clear delivery vehicles to bring structure to any agile project: epics, user stories, versions, and sprints:

Epic
Large body of work, contains stories
Story
Smallest unit of work, also known as a task
Version
The release of software to the customer
Sprint
Iteration where team does the work

By working with these vehicles, software teams are able to organize their work and break it down into do-able parts, so they can prioritize customer feedback and change from the original plan of the project without feeling like the walls have crumbled around them.

The ability to change and adapt future plans based on current insights is a hallmark of agility. In this article, we'll define these four delivery vehicles and show how they fit together to structure your work. But first, let's discuss the difference between each delivery vehicle.

Epic vs Story

Epics are larger bodies of work that stories roll up into. An epic can span across multiple sprints and versions. Versions are different from epics, because they are a point in time where software is released to the customer. A version might contain multiple epics. Epics help teams create hierarchy and structure. Stories help teams keep track of specific details for the task at hand and can be broken down into sub-tasks.

Epics vs stories - structure your agile project

The work shown in the chart above could be selected to be in a version that is completed during one or more sprints.

Initiatives happen at the portfolio level. It's important to point them out here so you can see that epics usually roll up into more strategic goals or initiatives. You can develop these initiatives when you are doing your long-term planning, and capture that work in a tool like Portfolio for JIRA.

What is an epic?

An epic is a large body of work that can be broken down into a number of smaller stories. For example, performance-related work in a release. An epic can span more than one project, if multiple projects are included in the board to which the epic belongs. 

Unlike sprints, epics often change in scope over time as a natural aspect of agile development. Epics are almost always delivered over a set of sprints. As a team learns more about an epic through development and customer feedback, user stories will be added and removed to optimize the team's release time.

Example of an epic

Depending on which agile framework you are using (scrum, kanban, or your own unique flavor), agile epics can be used in different ways.

For kanban, epics can be used as swimlanes to segment different streams of work. If you are using scrum, epics can help label the work in your sprints, like in the example below. Mission to Mars is an epic in this sprint. TIS 1, TIS 2, etc. are all user stories within the sprint (TIS Sprint 1). You can see, there are multiple user stories and epics within a sprint.

 

Want to give it a try? Sign up or log into JIRA Software >>

Select the type of project (scrum or kanban) and then follow one of these tutorials to help you get started setting up your epics:

Measure your epics

Burndown charts can also be used to visualize epics, which keep teams motivated and the executive stakeholders informed. A good epic burndown chart shows the agile nature of development. It's clear how the team is progressing as well as where the product owner added and removed user stories. Having these data points clearly visible keeps everyone on the same page and facilitates open conversation about the evolution of the product and completion forecasts. Not to mention that transparency builds trust!

ProTip: Feature "flags" (or "toggles") can be an effective means to develop larger epics because they let new code hide behind an on/off switch during development. Feature flagging gives the development team the ability to ship the code for an epic and let it be part of the production application, but not make it visible until it is fully implemented. (See our article on feature branching for more.) 

What is a user story?

A story or user story is the smallest unit of work in an agile framework. It is a software system requirement that is expressed in a few short sentences, ideally using non-technical language.

The goal of a user story is to deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.

User stories are a few sentences in simple language that outline the desired outcome. They don't go into detailed requirements.

Example user story

User stories are sketched out by the product owner, then the full product team collectively decides the more detailed requirements. These are the granular pieces of work that help define the implementation items for the story and the upcoming sprint.

In a story, there are a set of tasks required, these tasks should be fleshed out during estimation of the user story and linked in the team's issue tracker. 

Using the same example as above, the stories in this sprint have estimate, priority, assignee, epic and description showing, so everyone can get a quick view of the work being done.

Further reading: Decomposing User Stories

New to agile? Set up an agile project with this interactive tutorial >>

What is a version?

Versions are the actual releases of software out to customers. Remember, at the end of each sprint the team should be able to ship the software to customers. Versions are the curated changes the product owner actually ships.

Versions are often developed over a set of sprints, much like epics. Savvy product owners may choose to deliver an epic over several versions. An epic does not have to be fully contained within a version. By delivering an epic over several versions, the product owner can learn how the market is responding to that epic and make calculated decisions about its future direction rather than doing one giant release.

Example of a version

A product owner may structure the release strategy as follows:

  • Version 1: login, logout, password management
  • Version 2: purchase history
  • Version 3: saving preferences
  • etc.

Version scope change is also a natural part of agile development. Burndown charts keep the entire team abreast of how a version is evolving over time. Changes to a version should be discussed with the whole team to keep everyone on the same page.

Want to give it a try? Sign up or log into JIRA Software >>

What is a sprint?

A sprint is a short period in which the development team implements and delivers a discrete and potentially shippable application increment, e.g. a working milestone version. If you haven't run sprints before, we recommend using a fixed two-week duration for each sprint. It's long enough to get something accomplished, but not so long that the team isn't getting regular feedback.

Note: Sprints are only a part of the scrum framework. Kanban teams, by contrast, work on the next item in the backlog as capacity permits. No forecasting is required. 

In scrum, teams commit to complete a set of user stories during a fixed time period. Generally speaking, sprints are one, two, or four weeks long. It's up to the team to determine the length of a sprint. Once a sprint cadence is determined, the team perpetually operates on that cadence. Fixed length sprints reinforce estimation skills and enable the ability to predict the future velocity for the team once they have the data from several completed sprints.

Example of a sprint

Same example as above, the sprint in the image below, TIS Sprint 1, is the collection of user stories.

A couple things you should know about sprints:

  • Once a team commits to a set of user stories for the sprint, and the sprint is started, the scrum master is in charge of fending off changes to the user stories. This keeps the team focused and combats "scope creep" (adding work to the sprint after the sprint starts). Adding work mid-sprint compromises the team's ability to forecast and estimate accurately.
  • At the end of each sprint, the team is required to deliver a working piece of software. In scrum, that's called a potentially shippable increment (PSI). The product owner ultimately decides when the PSI gets released to customers, but the work should be complete enough to be suitable for release at the end of the sprint.

Measuring your sprints

A great tool for any scrum team are burndown charts. They clearly track progress throughout the sprint with "work remaining" on the Y axis, and "time" on the X axis. Burndown charts are a powerful motivator for the team, and they keep everyone focused during a sprint. Above all, these charts provide supporting data in discussions about the progress of a sprint. 

Scaling up

Larger organizations will often have several agile teams working on a common program, and portfolio planning is a key piece of running agile at scale. Epics and versions lay the foundation for solid agile portfolio management at the team level. Agile portfolio management encompasses tracking programs across several teams while retaining that same level of agility in higher levels of the organization. Learn more about agile at scale in the agile portfolio section. 

Product discussed
Project and issue tracking