Jira Epic

In Software Development

The basic principles of working in Jira will be explained: projects (Jira Epic), tasks and sub-tasks.

Share

Tweet

We will go through the stages of project planning with accessible examples. This is useful to know, not only in Jira, but also for all other task trackers, CRMs and schedulers. Alas, managers often forget where to start when setting up a task in order to see it through to completion.

Jira is a powerful task manager. Often too powerful for simple projects. But you can do everything you need in it. And if you understand the basics, you'll find that it's easy to work in it. Unfortunately, we often see this picture:

• A manager sees a huge amount of functionality.
• For each task, subtask, employee, department creates a unique process.
• Then everyone gets confused with these processes.
• It becomes impossible to unravel the chain of tasks and structure them.

As a result, you end up with a mess in your head, chaos in your work - the project is derailed.
To avoid this, it is enough to describe the company's work correctly at the start. Understand what types of tasks you face. Create and set up 5-10 processes, which are able to cover all the needs of the business. Everything becomes transparent and clear to the manager, project manager and all employees.

Scrum and other development methodologies use several different terms to describe what the team has to do. Each has its own meaning. The different names are meant to make it easier to understand, but if the terminology is not clarified, confusion ensues. And any misunderstanding impedes transparency and can lead to errors.

Let's explore together what the differences in the meaning of the terms are and how this affects evaluation and work planning.

What the Scrum Guide says

The Scrum Guide only outlines the necessary framework, but the team can adapt the framework and add new elements. This helps the work, but it also creates difficulties in interpreting the terms. Different teams, and even different sites and blogs, may use the same words to describe different entities. In our reality, the translation of terms into Russian also complicates things.

In Scrum, there are no "stories", "epics" or other divisions. In Scrum, the PBI (Product Backlog Item) is a product backlog item:

"The Product Backlog contains <...> new features or new product features, requirements, information on how to improve the product and fix defects. Each Product Backlog item should contain a description, a backlog item number, an estimate of the scope of work and a value."

It is these that are often classified as:

• Epics,
• Stories,
• Technical Tasks,
• Bugs, etc.

Thus, these are all PBI.

The idea of using User Stories was suggested by Alistair Cockburn, one of the authors of Agile Manifesto. In 2001, Ron Jeffries proposed the "3C" formula for creating stories, which is now often used to write them, although it is not necessary.

As 'someone', I want to 'accomplish something' in order to 'arrive at such and such a goal'.

A story can be completed in a sprint, meaning that it takes a few days. And the story itself is divided into tasks, which are short tasks that take no more than one working day to complete. Tasks take hours to complete.

Stories are rated in terms of SP (Story Points). The Fibonacci sequence and poker planning techniques are used. More detailed shuffles are evaluated in ideal hours, in order to take into account their possible capacity in hours.

A bigger element than the user story is the epic. It consists of several stories.

The fact is that the story doesn't always deliver value to the product on its own, and so must necessarily be complemented by other stories. In this case, in order to work simultaneously, user stories are combined into one epic.

In Essential Scrum book, an epic is defined as "a user story that is too big to fit less than one sprint".

Epics are used to reflect large tasks and broad requirements. When working on an epic, it is broken down into several stories, which are further divided into shuffles. But a story won't be considered fully finished until other stories from the same epic are ready.

Some epics can take several months to complete. They are usually evaluated using the "T-shirt size" method: each epic is assigned a value of XS, S, M, L, XL, XXL. This helps to estimate the task in a more abstract way, e.g. by the amount of estimated development costs.

Themes or features

Themes are synonymous with features. It is a group of related user stories. Grouping by themes is a way of indicating that the stories have something in common, e.g. they help to implement the same feature.

Not only stories but also epics can be combined into themes.

Some backlogging software uses the term "Epic" as a synonym for "Theme". Also, in the SAFe framework, both Feature and Epic have a different meaning. In it, they mean the realisation of a value, an idea at a different level of the portfolio.

The difference also applies to the ways of evaluation. We have mentioned popular techniques that have been tested by many developers, but each team chooses its own convenient way.

In any case, the scrum master must adapt the terms to the context in which the team works. There is no rigid requirement, but the main thing is to keep uniformity and to remember the different variants in order to understand people outside their team.

Epic vs Story

Epics are the largest objects representing multiple challenges. Epics can span multiple sprints and versions. Unlike epics, versions are counted by software releases, and can include multiple epics if necessary. Epics help the team create a hierarchy and structure, while stories help track the specific details of a task, and can be broken down into subtasks.

Epics usually boil down to more strategic goals or initiatives. These initiatives are usually developed during the long-term planning and development strategy process.

What is an epic?

An epic is a large amount of work that can be broken down into several smaller tasks. For example, a release performance study. An epic can cover more than one project if several projects are included in the board to which the epic belongs.

Here is an example.

Depending on which agile structure you use (scrum, kanban or your own choice) epics can be used differently. For kanban, epics can be used as guides to segment different work streams. If you are using scrum, epics can help to designate work in your sprints, as in the example below.

Mission to Mars is the epic in this sprint. TIS 1, TIS 2 etc. - all tasks in the sprint (TIS Sprint 1). You should notice that there are both tasks (stories) and epics in the sprint.

Evaluation of epics

Burndown charts are also used to visualize epics that keep the team motivated and inform the progress of the work to all stakeholders.

Such a chart clearly shows the nature of agile development. It shows how the team is progressing and when the customer has added or removed tasks. This transparent display of data allows anyone involved in the project to assess development forecasts, facilitates dialogue with the customer and trust at all levels.

What is a task?

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

The purpose of the user story is to return a specific state to the customer. Note that the 'customer' need not necessarily be external end-users in the traditional sense, they can also be internal customers or colleagues in your company who depend on your team.

User stories (tasks) are a few sentences in simple language that describe the desired outcome. They do not go into detailed requirements.

An example of a task is a user story

User stories are drawn by the product owner, and then the development team collectively tackles the more detailed requirements. Tasks are granular works that help define the elements of the implementation and the upcoming sprint.

Using the same example as above, the tasks in this sprint have grade, priority, successor, epic and description, so everyone can get a quick overview of the work in progress.

What is a version?

Versions are the actual releases of software to the consumer. Remember that at the end of each sprint the team must be able to send the software to the customer. Versions are the controlled changes that the product owner actually receives.

Versions are often developed over multiple sprints, like epics. An epic should also not completely "duplicate" a version. Thoughtful product owners can stretch an epic over multiple versions. By presenting an epic in multiple versions, the product owner can learn how the market reacts to that epic and make decisions about further product development, rather than making one giant release.

An example of using versions

A product owner can structure a software versioning strategy as follows:

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

The version change area is also a natural part of agile project development. The Burndown charts clearly show how the version evolves over time. Version changes should be discussed with the whole team to keep everyone informed.

What is a sprint?

A sprint is a short period in which the development team implements and delivers a discrete and potentially incremental increase in the application, e.g. a working version. If you haven't already had experience with sprints, we recommend using a fixed two-week duration for each sprint. This is enough time to get something done, but not so much time that you will experience a lack of customer feedback.

Sprints are part of the scrum structure. In contrast, kanban teams work on the next task as far as possible. In this case, forecasting is not required.

Scrum teams fix a set of tasks over a fixed period of time. In theory, sprints can last one, two or four weeks. 

A few things you should know about sprints:

• Once a team has fixed a set of tasks for a sprint, and the sprint starts, the scrum master prohibits task changes. This forces the team to focus and not be tempted to add work to the sprint after it has started. Adding work in the middle of a sprint compromises the team's ability to predict and estimate accurately.
• At the end of each sprint, the team must deliver a working piece of software. In scrum, this is called a potentially profitable increment (PSI). The product owner ultimately decides when the PSI will move to release. But the work must be complete enough to be suitable for release at the end of the sprint.

Sprint evaluation

A great tool for any scrum team are burndown charts. They clearly track progress throughout the sprint with 'remaining work' on the Y axis and 'time' on the X axis. Burndown charts and graphs are a powerful motivator for the team, and focus each team member on working on the sprint.

Scaling up

Larger organisations often have multiple agile teams working on a common project, and portfolio planning is a key part of agile work at scale. Epics and versions lay the foundation for robust portfolio management at the team level. Portfolio management covers tracking programs across multiple teams, while maintaining the same level of agility at higher levels of the organization. 

Jira EPIC F.A.Q

WHAT IS THE DIFFERENCE BETWEEN JIRA EPIC AND OTHER TYPES OF TASKS?

Stories, bugs and tasks are used to describe a single piece of work. Epics are used to describe a group of related issues. Epics can also be a large user story that needs to be broken down into smaller, more manageable chunks. Refer to our vehicle delivery guide for more information.

WHEN SHOULD I CREATE A JIRA EPIC?

Consider creating an epic if you have a large amount of work that needs to be completed in multiple sprints or over an extended period of time. You can also create an epic if you notice a pattern among several custom stories you've created and want to combine them into one group.

WHEN SHOULD I MARK MY JIRA EPIC AS DONE?

Mark your epic as done when all work on the epic is complete. To make this easier, we recommend coming up with a clear definition of a finished epic for its creation. Any stories associated with an epic don't have to be completed to mark the epic as completed.

Tip for professionals

• You can create tasks in the epic strip to quickly add a new task to the epic. This will also work if you have selected an epic in your filter.
• Outside the road map, you can also create epics from the global menu.