How do developers use Epics and User Stories?
Savvy Agile teams use specific terminology to describe their processes. Most of us know the basics. Some terms deserve a revisit, so that we ensure we are speaking about the same things. Today we will talk about a few terms used by software development teams to organize their Product Backlog Items (PBIs).
Read more on Product Backlog in Sprint Backlog vs Product Backlog: most important differences article.
Since different teams might adapt terms for their own needs, it’s important for us to define exactly what these terms mean. We need to have a common taxonomy in order to work together. So let’s talk about the meaning of Epic, Story and Tasks in Agile methodology. We’ll also give some concrete examples of each. Epic, Story and Task do not appear in the official Scrum Guide, but many teams today view them as invaluable tools in their process.
Software development teams use the terms Epic, Story and Task as part of the Scrum development process. In Scrum, teams tackle small parts of the larger project in time-boxed chunks called Sprints. They aim to complete the Sprint with new features and fixes, referred to as an Increment. Increments contain many items from the product backlog, known as Product Backlog Items, or PBIs. PBIs can be new features, enhancements or bug fixes. PBIs make up the foundation of the Sprint during Backlog Grooming. Teams use PBIs to map out their work.
What is an Epic?
Teams use the term Epic to describe a large feature or function in a project. Typically, Epics prove too large for teams to complete in one Sprint. The teams must break them into smaller pieces in order to complete them. Epics give teams a tool for estimating the time and resources necessary to complete their tasks. They use Epics to describe and understand the larger and higher priority features needed in the software development process. Epics also allow teams to give high-level understanding of their work to stakeholders without getting into technical details.
Examples of Epics in Software Development
Let’s say we want to create a new bicycle delivery service company customers access through an app or website. Our Epics might look something like this:
Registration: where customers and vendor set up their accounts
Maps: where delivery personnel plan their routes
Cost calculator: Based on timeframe and weight, the delivery cost is set
Billing: For customers who wish to pay monthly instead of at the time of delivery
Order tracking: where customers view their delivery’s status
What is a User Story?
Software development teams use User Stories to break Epics down into smaller parts. Specific tasks within the Epic become the User Stories. Teams then tackle these during the Sprint. We create User Stories by closely examining the requirements of each Epic. Some teams refer to User Stories as just “Stories.”
Read our Use Cases vs. User Stories article to have a better understanding of how the team uses user stories.
Examples of User Stories
Going back to our bicycle delivery service, our Stories for the registration process might look something like this:
Register with email
Register via Google account
Register via Facebook account
Register via Instagram account
Related post: Converting Story Points to Hours: Why Doesn’t It Work?
We will also need to create User Stories for the administration tasks and vendor tasks in our project. The team will create several different Stories for each role. This ensures that we examine every angle of development and code properly. User Stories within Epics give us a powerful tool to organize and understand our workflow and software function.
Learn more on User Stories and Estimating User Story Points in Agile.
What is a Task?
First Teams define large jobs with Epics. Then they break the Epics down into User Stories that they can complete in Sprints. Finally, they break the User Stories into Tasks. User Stories and Epics should be easy to understand by people outside the team. Teams should write User Stories and Epics with a general, non-technical audience in mind. The Tasks, however, can and should be written in technical language. The Tasks help the development team to understand the details of their Sprint. Teams can then plan out the hours required for each Task.
Examples of Tasks
In our bicycle delivery service example, our team might make connecting the Google map API a Task. The Task description would spell out in detail how the team would code the connection. They would plan out how the map view would work for customers as well as vendors and delivery people.
So, how do developers use Epics and user stories?
At the beginning of a software development project, teams will first map out the Epics. The Product Owner will then begin to prioritize which Epics the team should work on first. The Product Owner and team will break the highest priority Epics down into User Stories. Of these Stories, the Product Owner will choose which have the highest priority and designate them for the next Sprint. The team uses one of the backlog prioritization techniques during this process.
Teams use Epics to streamline their Product Backlog. Epics give teams a zoomed-out high-level view of work they need to complete. Product Owners use Epics to manage the Product Backlog. They see what large tasks they will break down into smaller User Stories.
Product Owners should break the Epic down into User Stories when they see Epic near the top of the backlog. If they do it sooner, requirements might change. Some User Stories will have a higher priority than others. It’s important to let the Epic guide the creation of User Stories in an organic way.
Using Epics, Stories and Tasks, software development teams plan with flexibility and control. Here at Blocshop, we harness all the power of Agile to deliver our project on time and under budget. If you’d like to learn more, please do get in touch!
