Christopher Clendening
96b7ff9766
- Create SECURITY.md to outline security policies and practices. - Establish WORKFLOW.md detailing the project lifecycle from planning to retrospective. - Introduce decision log structure in decisions/README.md for tracking architecture decisions. - Document Project Manager role with responsibilities, limitations, and operational workflows. - Implement templates for ADRs, bugs, meetings, projects, retrospectives, RFCs, roadmaps, and sprints. - Set up memory logs for architecture and company-wide lessons learned. - Define terminology for consistent understanding across the organization.
30 lines
868 B
Markdown
30 lines
868 B
Markdown
# Retrospective — Sprint <N>, <Project Name>
|
|
|
|
**Date:** YYYY-MM-DD
|
|
**Facilitated by:** Project Manager
|
|
|
|
## What went well
|
|
|
|
Concrete, not generic — specific enough that repeating it is actually actionable.
|
|
|
|
## What didn't go well
|
|
|
|
Same standard. Name the actual friction, not a softened version of it.
|
|
|
|
## Root causes
|
|
|
|
For anything in "what didn't go well" — why did it actually happen, not just what happened. This
|
|
is the section that turns a retrospective from a vent into something useful.
|
|
|
|
## Changes for next sprint
|
|
|
|
Concrete, ownable changes — not "be more careful."
|
|
|
|
- Change — owner
|
|
|
|
## Memory update
|
|
|
|
This is the section that matters most: what from this retro gets written into
|
|
`memory/lessons-learned.md`? A retrospective that produces no memory update didn't do its job
|
|
(`WORKFLOW.md`). List the exact entry (or entries) added, so it's traceable.
|