Engineering Cycles

Purpose of Cycle planning

We would like to address the above issues to provide a better way to do cycle planning going forward.

Things to maintain:

Flexibility and reactivity to priority changes
Minimal context switching for engineers
Contextualizing the work as part of the wider vision
A “why” to items on cycle plan

Proposal

2 x 2-week sprints of development
Mid Cycle check-in
1-week cooldown + planning
Product & Engineering retro during cooldown week

Timeline

Product Backlog Grooming

2 weeks before a short meeting to groom product backlog, and brainstorm things for future cycle.
- Action items for engineering: Come with potential items you want the product team to include and get more info/metrics/user interviews for.
1 week before the end of the cycle - deep dive into next cycle potentials
- Action items for engineering: Ask questions during the meeting, and familiarize yourself with potential next-cycle items and their definitions.

Cooldown week

At the start of the planning week, next cycle potentials are reduced in brainstorming sessions with the engineering team
Engineering begins breaking down with the product team.
- There will always be more items than the team can accomplish
- The aim is to figure out how to solve these problems within the timeframe
- Engineering should bring up tech debt issues or unresolved tickets
- Engineers should contribute ideas that they would like to work on
The team is to then go write RFCs/scope and descope with the help of the product and estimate what can and can’t be done within the timeline.
End of the Cooldown week on Friday - The team is to meet for a debrief to agree on the items that will be completed by the end of the cycle with sprint items for the first 2 weeks defined.

Non-negotiables

For each 2-week sprint, all items need to have all information for engineers to be able to execute on that task. I.e. no TBD items.
Within each 2-week sprint, no one is to interject add or remove items from the sprint unless it’s a P0.
- P0 in the engineering sense as defined here.
- P0 in sales - losing an enterprise customer
- P0 in ops - we’re unable to service customers within our SLAs
Items need to be delivered by the end of that sprint or cycle
- If items get interjected mid-cycle (2 weeks in) then items need to be removed from the cycle, this should be agreed upon with Head of Product.
Time in each sprint should be dedicated to tech debt, bug fixing, and responding to customers. At least 2 days of a sprint should be planned for this.

PreviousEngineering Values NextBest Practices

Last updated 6 months ago

Purpose of Cycle planning

We would like to address the above issues to provide a better way to do cycle planning going forward.

Things to maintain:

Flexibility and reactivity to priority changes

Minimal context switching for engineers

Contextualizing the work as part of the wider vision

A “why” to items on cycle plan

Proposal

2 x 2-week sprints of development

Mid Cycle check-in

1-week cooldown + planning

Product & Engineering retro during cooldown week

Timeline

Product Backlog Grooming

2 weeks before a short meeting to groom product backlog, and brainstorm things for future cycle.

Action items for engineering: Come with potential items you want the product team to include and get more info/metrics/user interviews for.

1 week before the end of the cycle - deep dive into next cycle potentials

Action items for engineering: Ask questions during the meeting, and familiarize yourself with potential next-cycle items and their definitions.

Cooldown week

At the start of the planning week, next cycle potentials are reduced in brainstorming sessions with the engineering team

Engineering begins breaking down with the product team.

There will always be more items than the team can accomplish
The aim is to figure out how to solve these problems within the timeframe
Engineering should bring up tech debt issues or unresolved tickets
Engineers should contribute ideas that they would like to work on

The team is to then go write RFCs/scope and descope with the help of the product and estimate what can and can’t be done within the timeline.

End of the Cooldown week on Friday - The team is to meet for a debrief to agree on the items that will be completed by the end of the cycle with sprint items for the first 2 weeks defined.

Non-negotiables

For each 2-week sprint, all items need to have all information for engineers to be able to execute on that task. I.e. no TBD items.

Within each 2-week sprint, no one is to interject add or remove items from the sprint unless it’s a P0.

P0 in the engineering sense as defined here.
P0 in sales - losing an enterprise customer
P0 in ops - we’re unable to service customers within our SLAs

Items need to be delivered by the end of that sprint or cycle

If items get interjected mid-cycle (2 weeks in) then items need to be removed from the cycle, this should be agreed upon with Head of Product.

Time in each sprint should be dedicated to tech debt, bug fixing, and responding to customers. At least 2 days of a sprint should be planned for this.