7

My question: Is there

  • a recommended format or
  • a procedure or
  • a check list

for documenting the sprint retrospective? Not only the immediate outcomes (i.e. measures to be tried in the next sprint), but also the other measures (for trying later), the problems and root causes.

During the Sprint Retro everybody in the team writes up the perceived issues on post its. We collect them on the white board, choose the most important ones, for which we try to identify the root cause(s) right there on the board. Then we come up with potential measures to tackle each of the causes. From the measures we choose two or three of the more feasible ones for the next Sprint.

Now my problem: Some time later in the day, somebody cleans the white board.

Hence my question: (see above)

Best would be in a format that could be used as additional input for the next retro ...

Improve this question
1
  • Thanks for the valuable input so far. I edited a bit to put more emphasis on the acutal question(s).
    – Gregor Ophey
    Commented Apr 4, 2014 at 11:42

7 Answers 7

Reset to default
6

I used to take pictures as well. Another possibility is having some (or many) take notes in a shared google doc. This also work for on-line retrospectives.

The key point, in my opinion, are any action points. It's all nice and fine to dig down to root causes, but in many cases it's quite unproductive: many root causes lay outside of the scope of the project team and there's little if nothing that can be done to address them adequately.

What are important are:

  • the issues ("start doing", "stop doing", "continue doing")
  • any actions to be taken, with somebody responsible for them

This does sound like "team-themed" stories, so I think documenting them as stories, can also be appropriate.

Improve this answer
4

I usually take a picture of discussion results on whiteboards. I can put them into most electronic tools or print them out to put them into a folder or pin them to the wall.

If the whiteboard works for your retrospective, I wouldn't change it. Most cellphones can make decent pictures, nowadays. You should point someone out who takes a picture after each meeting and places it somewhere for everyone to reach. Some Share, Dropbox, Google Drive, ...

Improve this answer
4

My team writes their issues on sticky notes and then attaches them to the white board.

Then, as a team, we try to group them into 3 main groups:

  • What went well (Keep doing)
  • What went poorly (Stop doing)
  • Ways to improve (Try doing)

I then collect these 3 "piles" of input and use them to craft a retrospective summary.

Improve this answer
4

I use a problem countermeasure board to keep track of the progress of the Action Items identified during the retrospective. I usually use Confluence, a Wiki or a dedicated whiteboard for the PCB.

Improve this answer
3

I recommend to use mind mapping tools to gather all outcomes of the retrospectives. By nature, mind mapping tools, you can easily group ideas, visualize root cause analysis outcome and mark action points. You can also export it in different formats, either to pdf or excel or jpg. I've been using it -I am using xmind as the tool by the way- for a long time and I get huge benefit from it. I hope that helps you too.

Improve this answer
3

Why documenting the Sprint Retrospective? What value does it bring?

All the things happening during the Sprint Retrospective are sacred for the Scrum Team. I would highly recommend NOT to document it.

Documenting the Sprint Retrospective destroys more than creates anything. All team members will understand that the discussions happening there are not safe if they are recorded.

Documenting it is not mentioned in The Scrum Guide™. And I think that's on purpose.

Besides, all the things that happened at Sprint X and were discussed during its Sprint Retrospective brings NO value in a later Sprint. Everything is linked with the context around it, and the precise context of this Sprint and this Sprint Retrospective is unique. Comparing or coming back to it just makes no sense.

If someone asks you for a Sprint Retrospective report, just answer that the things happening there are the sole property of the Scrum Team, and no one else. To make the Sprint Retrospective work, bring safety and an open stage for all.

As a Scrum Master, you are responsible to be the memory of the team in that regard, so if you collect the post-its, put them in a safe place and tell the team you keep them secret (same for the photos).

The only output of the Sprint Retrospective could be the action items discovered there, and if there are made public, it must be clearly agreed by the whole Scrum Team.

Improve this answer
1
  • 1
    I think the privacy and context aspect is important. The question isn't suggesting to document all that was said, just documenting the whiteboard at the end. It seems reasonable to keep this in a place that is shared with the team but no-one else.
    – icc97
    Commented Aug 21, 2018 at 9:39
3

These are good tools:

Lots of retrospective meeting format ideas.

Shared tool for collecting input from team members during a retro.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.