Four weeks have passed since the last sprint planning meeting. Sprint number two has come to an end. It’s time for the sprint retrospective.
The motivation for the sprint retrospective is:
- Visualize the accomplishment – important for the team morale
- Review any impediments and discuss measures on how to avoid them in the next sprint
Here’s how we are structuring the sprint retrospecives:
The set up
The team and the product owner are allocating one hour in the meeting room. We’re looking at the wall with the task board showing the user stories, the burn down chart and the impediment backlog. This is a big paper with a post it for every impediment encountered during the sprint. We collected the impediments during the bi-weekly scrum meetings (aka daily scrum).
Visualize the achievements
First, I go through all done user stories and say a few words about every story. Time for praising the team. Developers often think “we haven’t achieved anything”. So it’s important to visualize the finished user stories.
Getting the metrics
Second, we update the burn down chart and calculate the achieved velocity ([accomplished story points] / [available man days] = [velocity]). In our case we had 74 man days available. We accomplished 38 story points. That’s a velocity of 51%. Better than last time (39%). But still quite low as we committed for 50 story points. Fail. No praise here.
Learning the lessons
Third, we do the the retrospection round: This round is split in two parts.
First, we look at the conclusions from the last sprint retrospection a month ago. Were we able to implement the lessons learned? For example: We found that the product owner Martina did not have enough time to quickly reply to the questions of the team. As a measure we gave her an assistant. Did it help? – “Yes”, the team confirms, “Martina was did have a lower response time than during the former sprint”.. Good.
Then, we go through all the impediments we collected during the daily scrums. We discuss what we can do to avoid them during the next sprint. Example: “The changes on the CSS were much more complicated than expected because our CSS is the mess”. The conclusion is: “We plan a CSS clean-up”.
Results
This meeting took about one hour. The result is:
- key metrics about the past sprint (expected velocity vs. actual velocity etc)
- A list of impediments along with the measures to avoid them during the next sprint
The team now has one day of slack time before we do our third sprint planning on Thursday.
We have a slightly different approach.
1. Stick Postits with important events to the timeline.
Development is not only about hitting a velocity. Its more about living people working on something. In that process we found out that a lot of events occur that are not directly related to the sprint goal or the achieved result, but have something todo with it.
2. What was good.
A new flipchart is filled with postits, again everybody from the team can post as many as he/she likes. We group the Postits as we stick them to the
flipchart.
3. Bad Stuff / What can be done better
Everybody is allowed to post again. Grouping takes place as people feel their remarks are the same as the ones posted by other people before.
3.1 Sorting stuff out – We can change this / we can not change this
Again, teams decision since its all about what the people feel. Even bad code can be something a team feels it can not change for example. Yes, some can say eat your own dogfood, but that does neither go for code by people not anymore working ther nor for code developed by teamleads or people with better karma on a project.
The “We can change this ourself part”
Its not possible to get everything right. So exactly 2 Items are choosen from this list to be worked on during the next sprint.
We can not change this items.
These go directly to the scrum master. He is the one to go into the organization and start changing things that can not be fixed. All frm the can not change part goes as impediments to the specific backlog of the sm. No its time to start tackling your organization etc.
We had one slack day, and now beeing in the 4th or 5th iteration, i see the important part for this. Teams need to recreate, biggest learning for me, working scrum, even in 40 hrs week, is hard stuff. So its required.
One special point is: Do you have a review meeting? Doesnt sound like it? We hold the presentation of finished stories prior to the retrospective so all the “showoff and see we did something” part is done and not messing the goal of the retrospective. Its worth the time, try it.
Hi Sebs.
Thanks a lot for you very comprehensive report about how you do retrospectives. I think I will introduce two things for the next retrospective:
* having people writing the post its themselves instead of me doing it. It makes the meeting more interactive
* Writing down the good things also
Regarding the review meeting: The developer does a demo in front of the whole company whenever he’s finished a story. So we have the “Showoff” factor.
Ah we have more than one person providing us with work. Whenever something is getting to the done status in a sprinth, the developer has to talk to exactly this person, just to make sure out definition of done is covered.
Additionally we organise the showoff ;). Details come out of corporate culture i guess ;).
I talked to one of our fellow team members and he agreed on the day off thing and i guess we will do it like you now ;)))
Pingback: Dev Blog AF83 » Blog Archive » Veille technologique : Design, Navigateurs, Optimisations, Javascript, Ruby, Rails, Agilité, Outils