3SD handbook

Epics

Epics are a key building block for our client work - they are discreet chunks of work that contribute to specific business objectives, for example:

  • "Run the summer membership drive", or
  • "Set up online registration and back end admin processes for the training programme".

Epics are relatively large amounts of work (2-14 days) and are typically broken down into a set of smaller individual tasks.

Epics are a way to break projects down into manageable chunks of work that can be worked on reasonably independently. They should be well documented and easy to understand by both 3SD staff and the client.

You can read more about what epics look like, and their lifecycle in the epic process.

Epics and budgets

Epics are are key part of the budgeting process. Each epic has an estimate that is agreed with the client. We monitor work against this estimate and let the client know as soon as possible if we are likely to exceed the estimate. Any changes to the estimate should be agreed with the client 'in writing' (a comment on a ticket is fine).

We typically check on progress at 50% and 80% of the time estimate to judge whether we are likely to complete the work on time.

See epic estimates for more information on how epic estimates relate to client budgets.

Epics and Gitlab and dash

Epics are created in Gitlab as follows:

  1. Create an issue for the epic and give it the epic label.
  2. Create another label starting with the text epic: and ending with the title of the epic (this can be shortened if it is very long), for example epic: new website theme.
  3. Any issues that are part of this epic should also be given the label that you created for the epic.

Epics will now be visible in Dash at https://dash.3sd.io/tracking/project/.

Work that doesn't fit into an Epic

Not all of the work we do fits neatly into the above definition of an epic. For instance bug fixes, security releases and help requests from clients are not always easy to plan in advance, and they are typically ongoing for the duration of the relationship with the client. Never the less, we do create epics to account for this work in the following categories:

  • Support - ad hoc support requests (how do I do X, Y is broken, etc.)
  • Maintenance - required system administrator tasks, e.g. upgrades, security releases, bug fixes
  • Project management - monthly project management meetings, etc.

In each category

  1. Suffix the epic with the year that the work is agreed, e.g. epic: Project management 2022.
  2. Set a budget based on past experience (with this client and other clients)
  3. You can the record issues under these headings as they come in.

A couple of things to be wary of:

Ideally the support epic is kept reasonably small. If it is more than 15 days, consider whether some of that work could be better done in a more strategic way as part of a proposal, e.g. as part of a more well defined epic, or as part of a training epic for a specific member of staff.

Discovery

All epics have a discovery stage where we get to grips with the problem to be solved, understand the underlying motivations, etc. Sometimes this is simple and informal - this is often the case when we the work is tried and tested. Other times, it will be much more involved (e.g. when we are doing something new). Epics are designed to cater for both cases - see the epic process for more details.

How do epics relate to themes, projects and issues

It can help to think of the following hierarchy for organising our work:

Clients - The organisations that we are working for.

Projects - The work that we do for these clients. Project appear in Gitlab. Most clients have a single project but some might have more than one. For example if a client has two discreet websites we might create a separate project for each.

Proposal - A plan for work for a particular project, typically 6 to 12 months in length.

Theme - Proposals are often broken down into themes, for example website redesign, fundraising, events. Themes aren't always necessary for smaller projects but are often useful for larger projects that consist of lots of epics as a way to group related epics together.

Epic - (the subject of this page!) Epics typically consist of a multiple issues but simple epics may only require a single issue.

Issue - A small discrete piece of work that can be easily completed. It is often useful to break epics down into smaller issues so we can better track different aspects of the work on an epic.