(This column is posted at www.StevenSavage.com and Steve’s Tumblr)
So your sprint is done. Congrats. Now it’s time for the Retrospective!
The Retrospective is a big part of Scrum, and there are variants of it in a variety of Agile practices. It’s simply sitting down and asking yourself “how did it go,” finding things to improve, and improving them.
It sounds simple, and it is. That’s the point. It’s an obvious, common sense thing to do is regularly review and improve. It’s just not common enough in practice.
Think of it this way, it’s great to stop now and then and decide how to get better. You just gotta make room to review and improve, and Scrum – and my personal-life implementation of it – make it explicit.
So here’s what you do.
The Retrospective
First, set aside time for the Retrospective. It should always be timeboxed, and I use an hour. If it doesn’t take an hour, fine – if it does, well you stop anyway.
Here’s how I review in a Retrospective:
- First, ask yourself what worked. What kept you moving forward, getting things done, and what did you do right? It’s good to focus on the positive here, because if you do enough stuff right you’ll do less wrong.
- Secondly, ask yourself what went wrong. Focus on specific things that went wrong that are improvable. There will be stuff, trust me.
- Third, ask yourself what work you couldn’t get done and why. Note that’s not necessarily a wrong – maybe something wasn’t needed. But it let’s you figure out specifics.
- Fourth, ask yourself what work you discovered you had to do that you didn’t realize. Always good to keep yourself aware of surprises.
You probably have a lot of stuff. But now you gotta make it actionable. What I usually do is list down all the items above, prioritize them, and work in addressing what I learned (good and bad) in actionable items. Don’t just “not” do something, focus on doing better. Take a good thing and find ways to repeat it.
As you come up with actionable items, there’s a few ways to record them so they get done:
- New tasks in the Regular Tasks list. Often undiscovered work in my Personal Agile is something that reguarly occupies time at specific intervals.
- New things in your backlog or incubator – say if you want to edit better, set aside a few hours to read up on it.
- Habits you need to improve. I keep a list of what to improve and review it every few days.
Sounds overwhelming? It can be. So focus on the important things that you know you can address. Don’t overload yourself.
You’ll catch it next time.
Velocity
Velocity is a measure of how much work you got done in a Sprint. As you examine Velocity over time, you learn how much work you can take – maybe. There’s a few arguments about how to apply Velocity in Agile, so I’m going to give you my opinions.
Here’s how to get and use Velocity:
- Measure how much work you got done in that sprint. As noted I use hours of work.
- Keep a record of these hours per sprint (month). I keep a list in the same spreadsheet as my tracking lists. This lets me compare month to month and make notes.
- This gives you a rough idea over time of how much work you can get done at a given time.
- * As you plan sprints, look at your past Velocities to help you decide how much work you can do. This keeps you from overloading – or underloading – yourself.
- It helps you keep a reasonable amount of work, creating smooth, regular productivity. Note that’s helps because . . .
Here’s the thing, you can’t be sure the numbers are always perfect. Velocity is a guide, but each month is different, from holidays to illness to vacation. Each task is different, and sometimes things that take the same time can be mentally taxing or better done in different situations.
So I use Velocity as a a check, a suggestion, and a way to catch me overloading myself. But each sprint I also do a gut-check if I can really handle the workload I want to do, for those given tasks. Velocity is just one tool – but a good one.
What’s Next?
What’s next? Your retrospective is done. Time to end the sprint and start a new one!
– Steve
