2.3 Determining Duration

How long should your retrospective be?

It depends.

Fifteen minutes can be enough—or not. There’s no set formula. Base the length of the retrospective on four factors:

  • Length of the iteration

  • Complexity (of the technology, relationships with external departments, organization of the team)

  • Size of the team

  • Level of conflict or controversy

An hour-long retrospective can be enough for a one-week iteration; a half day may be enough for thirty days worth of work. Shortcutting time means cheating results. (Release and end-of-project retrospectives last longer: at least one day and up to four days in some cases.)

Complexity can be about the technical environment, or it can be about relationships. Add more time when there’s bound to be lots of discussion.

Add more time for more people. When more than 15 people are in the room everything takes longer.

Projects that fail and projects beset by politics generate controversy on the team and outside the team. Plan on more time for venting by team members.

You can always end the retrospective early if people identify meaningful improvements and finish their plans before the planned end time. There’s no point prolonging the retrospective once the team has achieved the goal. But too much time usually isn’t the problem. If your team produces only superficial insights and shallow plans, it may be that they need more time.

Get Agile Retrospectives now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.