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:
Large body of work, contains stories
Smallest unit of work, also known as a task
The release of software to the customer
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.
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.
Measure your epics
Les graphiques d'avancement servent également à visualiser les epics. Les équipes restent motivées et les responsables informés. S'il est efficace, le graphique d'avancement montre la nature agile du développement. Il affiche clairement la progression de l'équipe et indique à quels moments le responsable produit a ajouté ou supprimé des user stories. Une telle visibilité permet de synchroniser tout le monde et encourage à tenir une discussion ouverte sur l'évolution du produit et les prévisions d'achèvement. Sans parler du fait que la transparence est gage de confiance !
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
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.
Comme pour les epics, le développement des versions couvre souvent plusieurs sprints. S'il est avisé, le responsable produit peut décider de livrer une epic sur plusieurs versions. Une epic ne doit pas obligatoirement être complètement contenue dans une version. En livrant une epic sur plusieurs versions, le responsable produit est en mesure de déterminer la réaction du marché par rapport à cette epic. Il peut alors prendre des décisions en pleine connaissance de cause quant à l'orientation future, plutôt que de proposer une version géante.
Example of a version
A product owner may structure the release strategy as follows:
- Version 1 : connexion, déconnexion, gestion des mots de passe
- Version 2 : historique des achats
- Version 3 : préférences de sauvegarde
La modification du cahier des charges des versions constitue également un composant naturel du développement agile. Grâce aux graphiques d'avancement, l'équipe entière reste informée de l'évolution d'une version dans le temps. Les modifications apportées à une version doivent faire l'objet d'une discussion avec toute l'équipe afin de garantir la synchronisation de celle-ci.
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
Les graphiques d'avancement sont des outils extrêmement utiles à toute équipe Scrum. Ils montrent clairement l'avancement au sein du sprint : travail restant sur l'axe Y et dates sur l'axe des X. Les graphiques d'avancement sont une source de motivation pour l'équipe et permettent à tous de rester concentrés pendant un sprint. Surtout, ces graphiques fournissent les données justificatives à utiliser lors des discussions autour de la progression d'un sprint.
Gérer la croissance
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.