Scoping Out Software Development with Epics and User Stories

Too of­ten the same story re­peats it­self. A good idea is rushed into de­vel­op­ment with­out any plan­ning, forc­ing pro­ject man­agers to make crit­i­cal de­ci­sions on the fly. So how can we avoid this? We use epics and user sto­ries to cre­ate a re­quire­ments back­log. There are two key ben­e­fits to us­ing epics and user sto­ries. Firstly, we’re able to ac­cu­rately es­ti­mate the length of a pro­ject. Secondly, we en­sure each piece of func­tion­al­ity is well doc­u­mented. This avoids the age old prob­lem where a pro­ject owner thinks X is one thing and a de­vel­oper thinks X is some­thing dif­fer­ent.


An epic is a way of ex­press­ing a large piece of work to do. Epics usu­ally can’t be com­pleted by a sin­gle per­son, or in a sin­gle sit­ting. They will usu­ally have a num­ber of work tasks (expressed as user sto­ries) within them. Because epics are a high level view of a task, they are gen­er­ally not very de­tailed, but you do need to spec­ify the ba­sic in­for­ma­tion. We use a frame­work for epics which looks like:

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

Let’s look at an ex­am­ple. My hy­po­thet­i­cal ap­pli­ca­tion needs lo­gin func­tion­al­ity so that it iden­ti­fies who the user is and what per­mis­sions they have. As a [administrator], I want to [login] so that I can make changes on the back-end.

During the scop­ing pe­riod we firstly work with our part­ners to iden­tify their pro­jects epic level re­quire­ments. The cost es­ti­ma­tions that fol­low the scop­ing pe­riod can be fil­tered and grouped on an epic ba­sis.

User Stories

One epic may have mul­ti­ple user sto­ries but a user story can only be­long to one epic. User sto­ries are a stan­dard­ised way of ex­press­ing work that needs to be done. Our frame­work for user sto­ries is as fol­lows:

As a [type of user] like [persona] at [environment], I want to [do some­thing] us­ing [platform] so that [reason for task]. This will [achieve user goal].

So com­plet­ing the user story would give us: As a user like Jennifer at home, I want to pay me in­voices us­ing [platform name] so that I’m not in debt. This will help me or­gan­ise my fi­nances.

Type of User

When scop­ing out soft­ware de­vel­op­ment it helps to know which users will be on the plat­form. This is be­cause se­cu­rity and ac­cess to your soft­ware is con­trolled through user groups. These user groups are given dif­fer­ent per­mis­sion lev­els. In ef­fect that means a gen­eral web vis­i­tor can’t make changes to your ap­pli­ca­tion, but you can. It al­ways helps to con­sider who will be us­ing your soft­ware and what per­mis­sion they should have. For ex­am­ple; there might be site ad­min­is­tra­tors (full back­end ac­cess), white la­bellers (partial back­end ac­cess + front end ac­cess) and site users (no ac­cess).

When for­mu­lat­ing user sto­ries it helps to know who the func­tion­al­ity will ben­e­fit. Let’s say site ad­min­is­tra­tors need ac­cess to the ap­pli­ca­tion now but it does­n’t need to be ready for gen­eral users un­til 2019. Utilising user sto­ries and user groups al­lows pro­ject own­ers to pri­ori­tise re­quire­ments based on what’s needed.

If you’d like to learn more about our process and how we use epics/​user sto­ries, get in con­tact with us.


David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call