Documenting lessons learnt
Scrum is based on empiricism, utilizing numerous feedback loops in the form of Events (Daily Scrum, Sprint Review, Sprint Retrospective), but feedback comes from other places too (the marketplace, etc.). Inspection gives us validation, which enables adaption. What are some concrete methods of documenting that feedback? I'd hate to lose the feedback that we work so hard for.
I was just asking about the same thing. What kind of feedback are you referring to? The one we usually get at the end of the project from the whole team?
- Update the Product Backlog so it truly reflects the work currently believed to remain for the Product, thereby helping the Product Owner to maximize value.
- Improve the Definition of Done, so the potential for error and technical debt is reduced, thereby helping the Developers to better assure quality.
- Consider including Sprint Retrospective improvements in the Sprint Backlog, thereby helping their implementation to be visualized and managed.
+1 to @Ian Mitchell
I believe that the best way to document feedback is to apply it. Honestly, will the documented feedback be useful to you 3 months after it is received? If you apply the feedback when received, that feedback should be useless at a later date. The reason you strive for continuous feedback is so that it can be applied and acted upon at the time it is given. The best way I have found to do that is how @Ian Mitchell suggests.