Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've seen it done as a free-for-all where the scrum master just asks everyone to throw out comments. Or a time-boxed session where "anonymous" comments are posted on the walls bucketed by category. My current team is constrained by being spread out, so it has be done online/over the phone. What is everyone's best experience with soliciting constructive feedback? And how do you follow through on action items for improvement?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

Generally about the retrospective, I highly recommend this book : http://pragprog.com/book/dlret/agile-retrospectives

It is a short and very practical book. It explains all sorts of games, exercise and techniques to gather feedback in the different context your retrospective might be, the kind of team you have, and the current situation of your project. It helps a lot keeping a good dynamic in this kind of meeting, balancing the positive and negative feedback and analyzing properly all that info you have gathered.

I would also recommend The back of the napkin.

More specifically about your question, we dont know much about your environment, but keeping the chickens (authority) out of the retrospective can remove the 'fear' of sharing.

Another thing that has proven to work is to start the meeting with a simple 'check-in question'. Everyone express his feeling about the iteration in 1/2 word, no more, no question asks (yet). That breaks the ice and get everyone started on sharing/talking.

If people are not comfortable sharing in front of everyone, maybe make pairs of people sharing to eachother, and then everyone reports their findings/ideas?

share|improve this answer
add comment

A good start is to make note of issues that arise during the daily stand-up meetings. Also useful is to build a time-line of Sprint just completed, asking team members to bring up events and issues that occurred through the time-line - things that went right as well as things that went wrong.

Once items have been raised, it's up to the Team to figure out what they want to address and how they want to address it.

It's also important to understand that Sprint retrospectives aren't about "feedback". What the are about is implemented "continuous improvement" through the process of inspect and adapt. How does the Team make the things that worked well work even better in the future, and how do they fix the things that didn't work well?

The Scrum Master's role is to ensure that the Retrospective is held, and to coach the Team and keep them focused on the purpose of the Retrospective. Follow-through is really the responsibility of the Team, although it often helps to review the effects of prior action items in future retrospectives.

share|improve this answer
Can you elaborate a bit on the actual mechanics? Do you record the session electronically or on paper or not at all? Are topics suggested or is it wide open? –  jiggy Nov 9 '11 at 1:50
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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