However, in a 2 week Sprint a lot can happen. The Sprint could have started badly and turned out well, for whatever reason. In cases like this the retrospective will most likely focus on the points that are fresher in the memory rather than providing an overall view of the sprint.
To get more realistic actions from Retrospectives and to quicken the inspect and adapt cycle we often use Continuous Retrospectives. Our team write down any item they want to discuss during the Retrospective and add these to the task board.
We choose an appropriate number of items to act as a catalyst for a retrospective. So if our limit is 3 items, we must have a retrospective once any 3 items are added to the board.
This allows is to quickly resolve issues meaning we can see benefits immediately within the current sprint.
We choose an appropriate number of items to act as a catalyst for a retrospective. So if our limit is 3 items, we must have a retrospective once any 3 items are added to the board.
This allows is to quickly resolve issues meaning we can see benefits immediately within the current sprint.
That's an interesting idea. We usually have retros every 4-6 weeks and use the first part (about 20 min) to collect data about the past weeks to find out what we need to talk about. On one hand, it's true that things that happened towards the beginning of the iteration is not fresh on peoples' minds anymore, on the other hand, if it really were relevant today, people would remember, wouldn't they?
ReplyDelete