Engineering cycles

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.

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.

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.