The Lifecycle of an Epic¶
- Most epics are created following a discovery based on a client requirement. (For internal projects, the client is OpenCraft).
- If the client is not a client yet (a prospect), the epic is placed in the Prospect column. Once the discovery and corresponding estimates are shared with the client, the epic is moved to Offer / Waiting on client.
- If the client accepts the work, the epic is moved to Accepted.
- Once actual development starts, the epic is moved to In Development.
- Once the client's requirements are met, and the client has access to the completed work, the epic can be moved to Delivered to client / QA.
- The epic should be moved back from Delivered to client / QA to In Development if the client requests additional work or modifications that need development.
- When all the work in the epic is complete (for instance if all upstream PRs have been reviewed and merged) the epic can be moved to Done.
Recurring epics are generally not based on a project or discovery, but are used to track work for different cell roles (or long-running maintenance contracts for specific clients).
Tracking Epic Status¶
- Each cell has its own Epics board and epics, and is responsible for making sure that the projects represented by the epics are being properly delivered based on the lifecycle described above.
- To find the epics board for your cell, go to Boards > View all boards > Epics - <your cell> in JIRA. (Note that if you've recently accessed the board, it may also be listed under Boards > Recent boards.)
- Every sprint, status changes of individual epics from the past sprint should be reviewed and evaluated
to be able to keep both the Epics board and the epic planning spreadsheet up-to-date.
This involves making sure that:
- Each epic that is In Development has an epic update.
- New epics are moved through the set of initial states (Prospect, Offer / Waiting on client, Accepted) as appropriate until they reach In Development.
- Epics that have become blocked on the client are moved to Offer / Waiting on client.
- Delivered epics are moved to Delivered to client / QA.
- Completed epics are moved to Done.
- Every sprint, the epic planning manager should compare the Epics board for their cell
with the corresponding sheet(s) of the epic planning spreadsheet and update the spreadsheet
as necessary. This involves:
- Adding new clients and/or epics.
- Updating info about client and/or epic ownership.
- Removing entries for clients and/or epics from future months based on contract and/or completion status.
Recording High-Level Information about Epics¶
We keep a record of all epics that we work on (except onboarding epics) in the Time / Estimates sheet of the epic planning spreadsheet so that high-level info (such as who estimated and led an epic, and how long it took to complete) can be referenced as necessary in the context of future discoveries.
As part of the epic planning process, the epic planning manager is responsible for keeping the Time / Estimates sheet up-to-date by:
- Adding entries for new epics.
- Updating entries for completed epics.
Tracking Cell Member Availability¶
To be able to determine capacity allocations for individual projects, we need to track cell member availability. As an epic planning manager you should:
- Keep a look out for newcomers and core members joining or leaving the team,
and add their details to the epic planning spreadsheet.
- For newcomers this includes adding onboarding time to the onboarding section and specifying their availability in the availability section of the epic planning spreadsheet. Only make these updates when the corresponding information is fully public, i.e., the newcomer should know whether they have been accepted or not by the time these updates are made.
- Availability for each member is calculated in full-time weeks.
For example, if someone's commitment is:
- 40h/week, their availability will be
40 / 40 = 1.
- 30h/week, their availability will be
30 / 40 = 0.75.
- 40h/week, their availability will be
- If you prefer, you can also specify availability of individual cell members in hours per week. Just note that if you do, you'll also need to modify the calculation of total availability accordingly. (I.e., instead of just summing up the availability of the cell members to get the number of person-months available for each month, you'll need to sum up the weekly hours and divide the sum by 40.)
- For team members leaving the team, make sure to remove (or reset to zero) their availability for the remaining months of the year.
- Handle requests from cell members to change their weekly hour commitments,
if the requested commitment is in the range of 30-40h per week:
- Outside of that range, refer to the CEO: We generally avoid commitments that are
lower or higher than 30-40h/week because they may
- prevent cell members from taking some types of tasks,
- increase overhead for commitments below 30h/week, and
- can lead to burnout for commitments that exceed 40h/week.
- However, temporary changes lasting 1-2 months that fall outside of the 30-40h/week range are generally acceptable.
- If you need time to implement the change, for example to finish a round of recruitment, don't hesitate to discuss a specific date at which to make the change. Generally we agree to requests for changing weekly hour commitments, but not necessarily to implementing them immediately.
- To implement the requested changes:
- Update the cell member's availability in the epic planning spreadsheet to take the impact on your cell's total availability into account for epic planning.
- Update the cell member's hours by via Tempo > Administration > Workload schemes1:
- Locate the team member's current workload scheme (e.g. 35h), and click Members.
- Click Move to move the team member to the new workload scheme (e.g. 30h).
- Outside of that range, refer to the CEO: We generally avoid commitments that are lower or higher than 30-40h/week because they may
- Check the calendar for vacations coming up in the next couple months:
- If someone has scheduled time off for a total of 1 week or longer, comment on the cell(s)
in the epic planning spreadsheet that represent their availability for the month(s)
during which they will be away:
- Mention the number of weeks they will be away.
- Mention the remaining availability for the affected month(s).
- Don't change their availability for the affected month(s) in the spreadsheet: Holidays are already taken into account in the holidays buffer, which reduces the cell's monthly availability according to the cap on the number of cell members that can be off at the same time. (That cap is usually 20%.)
- If someone has scheduled time off for a total of 1 week or longer, comment on the cell(s) in the epic planning spreadsheet that represent their availability for the month(s) during which they will be away:
- Keep Role statistics for your cell up-to-date.
- Keep the Discovery Duty rotations up-to-date in the Weekly Rotations Spreadsheet, taking into account latest role statistics.
- This can happen at any time during the sprint, as long as the spreadsheet is checked at least once per sprint, and updated as necessary.
- Discovery budget: 2.5% of the cell's total work hours (10h/week for 10 full times). The discovery budget and the discovery duty allocation are two different things. The weekly discovery duty allocation (5h/cell/week) is to be used for new tasks that pop up over the course of a sprint - it is funded by the discovery budget. Any leftover discovery budget can be used for discovery tasks that are planned in advance.
- Members with a medium to high role load should be removed from DD rotations and re-added when their role load drops to a level that lets them take on new epics.
- For each client and epic, maintain a count of the amount of time required to complete the accepted
project scope over the next months in the epic planning spreadsheet
for your cell. This is used to inform recruitment needs (cf. below).
Note that the amount of time required to complete the accepted scope of a project
isn't always equal to the estimated budget for the project:
- Work may progress more quickly than expected in some cases, allowing us to reduce capacity allocations for coming months.
- In other cases there might be a need for additional work that was not accounted for in the original estimates, requiring us to increase capacity allocations for coming months.
- Ensure delivery and bugfix deadlines for individual epics are on target.
If that's not the case, comment on the epic(s) or directly on the epic planning spreadsheet,
pinging epic owners as necessary and reminding them to:
- Determine the impact of shifting deadlines and figure out how to minimize it.
- Discuss the situation with the client (or the CEO in the case of accelerated epics), negotiate scope adjustments as needed, and make sure that the client (or CEO) is OK with them.
- Coordinate with the team's recruitment manager to slow down/speed up recruitment as necessary.
Private for OpenCraft Employees ↩