Epic Process
This page contains an overview of our epic process - or to put it another way the life of an epic. For more details on what epics are and how they fit into the bigger picture, see epics.
The process is broken down into a number of steps, some of these steps are simple and straight forward. Others are a bit more involved. Each step includes pointers on what should be done and a checklist to ensure that it is complete.
Epics are key to doing the best possible work for clients, so it is important that we all understand this process and are on the same page with regard to how we work. The process is tried and tested based on the things that we have found work best when doing client work.
That all said, this process is by no means perfect. If you think there are problems with or things that we could improve about this process, please create an issue so we can discuss and take appropriate action. Similarly, if we aren't following the process outlined here, we should talk about why not, and what changes we need to make to bring our work and this process back into line with each other.
[DOUBLE DIAMOND EPIC DIAGRAM]
A visual outline of the epic process.
Where do epics come from?
Ideas for epics come either from clients or from ourselves. They may be things that we want to do, but they may also be things that we are required to do due to external constraints
Here are a few examples:
- a potential client may send us a requirements document which we translate into a series of epics in a proposal
- we suggest a way that an existing client can improve a business process by taking advantage of some CiviCRM functionality.
- an existing client starts a new project and ask us to provide the tech infrastructure to support that project.
- we conduct an annual review and planning exercise with a client and a new set of epics in a proposal for the client
- a technological platform reaches end of life and we need to migrate away from it.
Where possible, we like to plan all of our epics in advance in a proposal. This provides us with a systematic way to assess what we want to do with a client over the next 6 - 12 months.
Inevitably, from time to time, clients will request that we do work at short notice and we will do our best to accommodate their requests (as long as it does not negatively impact other clients work).
Regardless of where the idea for an epic comes from, the first step in the epic process is to write an epic description.
Description
The description is a high level overview of the epic. It should allow someone that is familiar with the client to understand the challenge we face and the the approach we are taking. It also includes an estimate for how long we think it will take to complete.
Epics are diverse and there is not a one size fits all template for writing a description. However there is a list of areas to address in each case, see epic descriptions for some pointers.
Once drafted, the description should be reviewed by a colleague who should feedback and suggest improvements. Specifically, they should ensure that
- it covers all areas mentioned in epic descriptions
- the estimate is realistic
Checklist:
- Has it been reviewed by a colleague?
- Does it covers all areas in epic descriptions?
- Does it have a realistic estimate?
Feedback and sign-off (description)
Once the description has been reviewed internally, it is ready for feedback from the client. For epics in a proposal, this process will likely happen as part of a review of the entire proposal.
TODO: create a list of questions to help clients feedback on each epic.
Checklist:
- Have we collected and documented feedback from the client?
- Do we have written sign of on the epic?
- Is the epic in Gitlab and with the description in the issue description?
Add to pipeline
Once the client has signed off on the epic, it should be added to the pipeline according to our availability.
Epics that are part of a proposal will typically be added in bulk when the proposal is approved. They may also be provisionally added before the proposal is completely signed off if we are confident that the work will happen.
If an epic comes in outside of a proposal that a client wants to prioritise, and we agree that it has to be prioritised, we will do our best to fit it in.
Essentially, this means that we will have to reschedule existing epics. We need to do this in a way that has minimal impact on other clients.
- The preferred option is to reschedule existing work for this client.
- If no existing work is in the pipeline, we can consider moving work in our internal pipeline
- If As a last resort, we could delay existing work for another client but this should be avoided if at all possible.
While we should do all we can to accommodate client demands, we also want to encourage good project management on their part. If a client continually makes requests for urgent work which are arguably due to a lack of project management on their part, we should consider telling the client that we cannot meet their deadlines and explain why. Hopefully this will encourage better planning on their part in future.
Checklist:
- The epic is in the pipeline and has been assigned to staff
- Staff have been notified so they can review the epic description
- The epic in Gitlab has a milestone added.
Discovery
Some epics will involve considerable amounts of discovery. Others may not require any significant discovery. When discovery work is required, we need to ensure the client is fully prepared for this work, that we carry it out using tried and tested discovery tools, and that the results of any discovery are properly documented, both for this epic and for any future epics.
See the discovery toolkit and talk with Farzan or advice on how to make the most out of discovery.
TODO: how does this relate to the Discovery Report Template?
Checklist:
- Any artifacts and outputs from discovery have been presented to the client and documented (both for this epic and future work)
Define
Once the discovery has been completed, we can revisit the epic description to further define the epic. For example, we might reformulate the challenge and the proposed solution. We may also want to provide more detail on the work that needs to be done. The final definition should be reviewed by a colleague who should feedback, suggest improvements, and ensure that the estimate is realistic.
TODO: how does this relate to the Discovery Report Template?
Checklist:
- Has the description been updated and reviewed by a colleague.
Feedback and sign-off (definition)
Once the definition has been reviewed internally, it is ready for feedback from the client. If the estimate has changed then we will need to run this by the client.
Checklist:
- Have we collected and documented feedback from the client?
- Do we have written sign off from the client on the epic?
Update Pipeline
If the estimate has changed, we will need to update the pipeline with the more accurate estimate. This may involve re-prioritising existing commitments with this client
Checklist:
- The pipeline has been updated inline with the new estimates
- The client has been informed of the new estimated completion date
Design, develop, test and launch
At this stage we can start the design and development work.