> 3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Mas

> 3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Master to belittle developers for mistakes and missed goals. When I was running retros, I created a document which recorded reasons tasks weren't finished. If you had more than 1-2 points left at the end of a sprint, you edited the doc, and either added a new reason, or just increased the tally on an existing reason. The doc didn't have edit history enabled, so it was (mostly) anonymous. We'd review it every retro, and look for ways we could improve. A huge problem was not accounting for personal issues. We had people who were trying to take an entire normal load of tasks during the week when they were moving to a new apartment. We had true unlimited time off at this company, so there was no reason not to just take a day off. So, new explicit guideline: Take time off for your personal life. Stop trying to cram in a full week's work when you know you'll be distracted. The team will get by fine without you, and you'll be happier when you come back. The trouble, of course, is that these sorts of things require a high level of respect amongst the team, and sometimes that's missing. So, really, you need to work on culture before you can adopt these tools.