mjhjmtu

Our Scrum master wants us to document our feedback for the iteration before our Retrospective. Her argument is that she wants us to have time to document our feedback. Another guy on the thinks that we should be documenting our feedback during the meeting or right before the meeting.

I'm a college hire so I'm still learning how best to do this. Is there a proper way we should be handling our Retrospective feedback?

There's no prescribed way to document Retrospective feedback, but there are some things to consider.

The most important thing to consider is that the team needs to be able to be open and honest. If you are using an electronic tool and requiring people to complete retrospective notes before a meeting, then it is likely that the authorship of those notes may be tied to individual people. The people involved may be more likely to not be completely open and honest if they know that others from outside the team can see what they are writing.

That said, it is important to be prepared for the retrospective to make sure the time is well used. Perhaps allowing the team to add notes to an electronic tool is a good way to do that. But it needs to be balanced with the free, open, and honest communication between team members. I would think that it is unreasonable to have a "finished" retrospective page before the meeting and not be editing it during the meeting.

From my perspective, the most recent team that I worked with used Confluence for retrospective notes. The retrospective page was posted early in the Sprint and the team could optionally add notes to talk about so they wouldn't forget things. However, at the retrospective itself, I (as the Scrum Master for the team) was making additional notes and edits so further discussion couldn't be tied to individual people. The only expectation was that the team come prepared to have the discussion, and it seemed to go over well with the team.

The team should be empowered to choose their way of working to the extent possible based on the constraints of the organization. Your Scrum Master should not be dictating the way your team works, but coaching you on effective techniques and enabling you to do the work that needs to happen.

Focus on the problem and try to come up with good solutions, as a team.

Canonically speaking, do whatever works for your team.

That said, I'd suggest that A two-phased approach to documentation is ideal.

Phase 1: Before the retro, each team member documents their own feedback privately.

Phase 2: During retro, perform a round of "what went well" followed by a round of "what didn't go well." Document the main points, decisions, and action-items.

Remember, the primary goals of the retrospective are to drive change and reinforce good processes. That won't happen without discussion and consensus. Discussion won't occur if no one comes prepared to talk. And change/reinforcement won't occur if the team doesn't document it — ideally together.

Personally, I really appreciate when my team members spend time articulating and documenting their feedback ahead of time individually. It ensures that a discussion actually occurs. And, it helps to ensure that nothing important is left out of the team's documentation in the wake of any tangential discussions.

^{(Also remember, the retrospective process is one of the processes you're free to discuss during the retrospective!)}

First, keep in mind the method for documenting the feedback is itself subject to the retrospective process. If you don't like how documenting feedback is done, bring it up in the retrospective. Most teams I have been on try many different ways until they find one they like, then stick with it, perhaps occasionally shaking it up.

My main concern with feedback given in writing before the meeting is that sometimes leads to it not really being discussed thoroughly. Also, sometimes the tone and meaning is not precisely communicated to the other team members. If you are having a thorough discussion and updating the documentation based on the discussion (whether in real time or afterward), then it can work okay.

Gathering data/input (= feedback) for the retrospective can be done before the retrospective meeting, in the meeting, or both (combined). Below are some advantages and disadvantages of each approach.

Gathering data before the meeting

You can collect data before the meeting using a shared document or workspace, like Google doc, Confluence, Wiki, Slack, etc. Alternatively, as the facilitator you can ask the participants to send their input to you where you collect it and will distribute it to the team before or at the start of the meeting.

Advantages:

• Gives people more time to think about their retrospective input


• They can prepare their input when time permits them (time and place independent)


• Sometimes when people reread their input it makes them think of additional things or better formulations


• Makes it easier for introverts to share their opinion


• Possible to avoid groupthink (if people don't see each other's input)


• The facilitator can review the input and ask for additions or clarification before the meeting


• You can use questions to focus input on a specific topic


• Easier for people who prefer writing over speaking (note that this can also lower language barriers for retrospectives in non-native languages)

Disadvantages:

• People might forget to give input or don't have time for it


• You may have to follow up if people aren't disciplined enough to deliver input


• The amount and quality of the input can vary between people

Gathering data in the meeting

Advantages:

• As a facilitator, you can interact directly with people when they give input


• It ensures that there is time for everyone to give input


• You can timebox it, and when needed extend the time window if more input is needed

Disadvantages

• Part of the meeting time is spent on gathering input, so you may have less time for analysis and actions (unless you plan more time for the meeting)


• People who are more vocal might inhibit others to speak up (there are ways to deal with this)


• Might lead to groupthink where people who think differently about a topic don's speak up

Depending on your situation and the advantages and disadvantages I suggest using the approach which fits best. Or experiment and find out what works for you in which situations.

I work at in large corporate environment with a fairly modern style of Agile Scrum. At the beginning of each sprint, our scrum master posts an anonymous Sprint Board for each team (ie. Devs have their own, QA has their own, etc). It's just a web page public to anyone on our VPN, and the link is only given to individuals on the team. The board has 3 columns: What Went Well, What Went Poorly, and What Should We Be Doing.

As the sprint goes by, people add things to the board. On the last day of the sprint, we have a meeting (which is booked well in advanced) where each team sits down with the scrum master(s), and go through the items on the board.

Some benefits of following this process are:

1. People are generally more honest as it is anonymous and nobody is obligated to claim they put an item on the board.


2. Although we are free to take notes, everyone is also able to prepare well in advanced for the upcoming meeting as we only focus on topics brought up by items on the board.


3. As things pop into your head throughout the sprint, you can add it to the board immediately.

I'm not claiming this is the best way, but throughout my career I've seen different teams try different implementations of Agile Scrum and my current company is by-far the smoothest experience I've had.

Hope this helps,

Cheers!