Implement lessons learned

Lessons learned, retrospective, learning loop; it’s all aimed at improving the next project or the following iteration. In below article the terminology ‘lessons learned’ is used, but naturally this can also be the outcome of an Agile retrospective.

After a review, especially if it was a review that needed some attention, the moderator can initiate the lessons learned administration. The lessons learned can be aimed at the review process, the reviewed product or generic aspects.

It is useful to determine which of the lessons learned must lead to fine tuning of the review process and which can lead to improvement of future reviews to be executed. Most of the the improvements or attention points related to the document, the author or the subject at hand will be temporary. A good practice is to assign a planned end date to an individual attention point. When the end date approaches the attention point needs to be validated. If it’s still valid, the end date is moved forward.

Attention points for future reviews can be related to a

  • specific author (newbie on the subject, textually not strong, using new tools or diagrams etc.)
  • specific subject (high business value, very complex matters, high amount of integration with other systems etc.)
  • specific document type (requirements, interface designs etc.)

The moderator can keep a log for these attention points to be used in the review requests or as checklist in the review forms.

Risk assignments logFor example:

Hi John,

Herewith I kindly request you to review the document VSPA-FReq1610_v0.4.docx which is attached to this mail. Please fill out the bright blue fields in the attached review form and send it back to me before 29-10-2014 15:00.

In your review, please focus on the following:
Each functional requirement must be traceable to a business requirement

Included attachments:
•  VSPA-FReq1610_v0.4.docx
•  VSPA-BRreq1610_v1.3.docx (reference, not to be reviewed)

Planning of the review:
… etc.