Use Improvement Stories to Make Your Retrospectives More Effective
I teach a one-day class on retrospectives. It’s in Swedish only for now, but if that’s not an obstacle, you should read about it on the Citerus web site.
I love to use the user story format when I help teams plan their work. It can sometimes be hard to break user stories down into useable chunks, but their format is very easy to use: As a
Maybe you’ve noticed that it’s not just during planning that we have hard time putting our thoughts and desires into words. Teams that do retrospectives frequently find that it can be very hard to get valuable output from these meetings. One cause of this, which is easy to remedy, is the use of inexact language.
If you’ve brainstormed improvement suggestions with your team, you might have seen a suggestion like this (written on a post-it note): “Better test”. Or maybe even terser: “Cooperation”.
These notes are a good start, because there’s an interesting story behind them. The problem is that we might have to spend considerable time pulling that story out. There is a simpler way to get there.
Nowadays, I use the story format not only in planning meetings, but also in retrospectives. Whenever I ask a team to brainstorm improvement suggestions, I ask them to do it using a template I supply. I ask them to write Improvement Stories.
An improvement story is quite easy to write, and looks like this:
Because
we should
so that
I find that asking teams to supply their suggestions in this format results in contributions that are well considered, easy to understand and quick to process.
Have you tried using improvement stories? Drop me a note in the comments section!
Comments
I really like the format, as it encourages forming good improvement goals. However, I feel that the heavier form would cause me to procrastinate from coming up with improvement suggestions or issues, because I may not have all three components fully formed in my head. But once raw issues are on the table ("Better tests"), it seems like a good team activity to try and form full improvement stories ("Because we always spend 20% of our iteration time fixing critical production issues we should put some energy into improving our tests so that we can work with better focus on delivering value") Thanks!
Morgan: thanks for the comment. I've used the improvement stories during a brainstorming session. This has been preceeded by collection and analysis of data and a review of what went well, etc, during the sprint. Haven't learned what an IO map is yet.
Kim: thanks for commenting! So far, I've gotten as many improvements with this format as before I started using it. I should point out that I've asked participants to write these stories during a silent brainstorming, i.e. a session where people write on their own and in silence. We do this for 5-10 minutes, or until people starting putting their pens down for good. I like this way of doing it, because it supports those with an introverted preference. Once the silent brainstorming is done, the group presents its suggestions to each other. Because the format is rich, understanding each others stories is easier than usual, which also makes it easier to, for example, rank them.
[...] Tobias Fors » Blog Archive » Use Improvement Stories to Make Your Retrospectives More Effective www.tobiasfors.se/?p=533 – view page – cached I love to use the user story format when I help teams plan their work. It can sometimes be hard to break user stories down into useable chunks, but their format is very easy to use: As a , I want to , so that . There are different ways to format stories, but the essence remains the same. Use a simple format to quickly shake out some key information about a given requirement. [...]
I like the format a lot. It should leave you with a good traceability of your process evolution and practices so future teammembers can understand the path that has led you to where you currently are. However (isn't it always "however"?), do they formulate these stories up front or do you perform a root-cause-analysis of some sort and then document the solution with the story? If this is a root-cause-solution to a system problem the connection between the suggestion and the desired result might not be that obvious. Maybe a simple IO-map on the back of the card would handle that ... but that would kind of kill the beautiful simplicity. I don't know. Anyway, thanks for the idea. I'll take it with me. BR Morgan
Cool, thanks for the experience report! I'll see if I can try it out at some point.