Your Task Design Title Here (prefix with DRAFT/WIP to indicate level of completeness)
When developing a design document for a new task, it should contain a detailed design proposal demonstrating how it will solve the goals outlined below.
Not all tasks require a design review, but when they do it is likely that there many unknowns, or the solution may be more complex. The design should include diagrams, pseudocode, interface contracts as needed to provide a detailed understanding of the proposal.
- Task Name
- Story Name
- Engagement: [Engagement]
- Customer: [Customer]
- Authors: [Author1, Author2, etc.]
Overview/Problem Statement
- It can also be a link to the work item.
- Describe the task with a high-level summary.
- Consider additional background and justification, for posterity and historical context.
Goals/In-Scope
- List a few bullet points of what this task will achieve and that are most relevant for the design review discussion.
- This should include acceptance criteria required to meet the definition of done.
Non-goals / Out-of-Scope
- List a few bullet points of non-goals to clarify the work that is beyond the scope of the design review for this task.
Proposed Options
- Describe the detailed design to accomplish the proposed task.
- What patterns & practices will be used and why were they chosen.
- Were any alternate proposals considered?
- What new components are required to be developed?
- Are there any existing components that require updates?
- Relevant diagrams (e.g. sequence, component, context, deployment) should be included here.
Technology Choices
- Describe any libraries and OSS components that will be used to complete the task.
- Briefly list the languages(s) and platform(s) that comprise the stack.
Open Questions
List any open questions/concerns here.
Additional References
List any additional references here including links to backlog items, work items or other documents.
Last update:
April 25, 2022