Milestone / Epic Design Review Recipe¶
Why is this valuable?¶
Design at epic/milestone level can help the team make better decisions about prioritization by summarizing the value, effort, complexity, risks, and dependencies. This brief document can help the team align on the selected approach and briefly explain the rationale for other teams, subject-matter experts, project advisors, and new team members.
Things to keep in mind¶
- As with all other aspects of the project, design reviews must provide a friendly and safe environment so that any team member feels comfortable proposing a design for review and can use the opportunity to grow and learn from the constructive / non-judgemental feedback from peers and subject-matter experts (see Team Agreements).
- Design reviews should be lightweight and should not feel like an additional process overhead.
- Dev Lead can usually provide guidance on whether a given epic/milestone needs a design review and can help other team members in preparation.
- This is not a strict template that must be followed and teams should not be bogged down with polished "design presentations".
- Think of the recipe below as a "menu of options" for potential questions to think through in designing this epic. Not all sections are required for every epic. Focus on sections and questions that are most relevant for making the decision and rationalizing the trade-offs.
- Milestone/epic design is considered high-level design but is usually more detailed than the design included in the Game Plan, but will likely re-use some technologies, non-functional requirements, and constraints mentioned in the Game Plan.
- As the team learned more about the project and further refined the scope of the epic, they may specifically call out notable changes to the overall approach and, in particular, highlight any unique deployment, security, private, scalability, etc. characteristics of this milestone.