Please note that this blog is archived and outdated. For the most current information click here!

Scoping Out Software Development with Epics and User Stories

Too often the same story repeats itself. A good idea is rushed into development without any planning, forcing project managers to make critical decisions on the fly. So how can we avoid this? We use epics and user stories to create a requirements backlog. There are two key benefits to using epics and user stories. Firstly, we're able to accurately estimate the length of a project. Secondly, we ensure each piece of functionality is well documented. This avoids the age old problem where a project owner thinks X is one thing and a developer thinks X is something different.

Epics

An epic is a way of expressing a large piece of work to do. Epics usually can't be completed by a single person, or in a single sitting. They will usually have a number of work tasks (expressed as user stories) within them. Because epics are a high level view of a task, they are generally not very detailed, but you do need to specify the basic information. We use a framework for epics which looks like:

As a [type of user], I want to [do something] so that I can [achieve a goal].

Let's look at an example. My hypothetical application needs login functionality so that it identifies who the user is and what permissions they have. As a [administrator], I want to [login] so that I can make changes on the back-end.

During the scoping period we firstly work with our partners to identify their projects epic level requirements. The cost estimations that follow the scoping period can be filtered and grouped on an epic basis.

User Stories

One epic may have multiple user stories but a user story can only belong to one epic. User stories are a standardised way of expressing work that needs to be done. Our framework for user stories is as follows:

As a [type of user] like [persona] at [environment], I want to [do something] using [platform] so that [reason for task]. This will [achieve user goal].

So completing the user story would give us: As a user like Jennifer at home, I want to pay me invoices using [platform name] so that I'm not in debt. This will help me organise my finances.

Type of User

When scoping out software development it helps to know which users will be on the platform. This is because security and access to your software is controlled through user groups. These user groups are given different permission levels. In effect that means a general web visitor can't make changes to your application, but you can. It always helps to consider who will be using your software and what permission they should have. For example; there might be site administrators (full backend access), white labellers (partial backend access + front end access) and site users (no access).

When formulating user stories it helps to know who the functionality will benefit. Let's say site administrators need access to the application now but it doesn't need to be ready for general users until 2019. Utilising user stories and user groups allows project owners to prioritise requirements based on what's needed.

If you'd like to learn more about our process and how we use epics/user stories, get in contact with us.