Lessons learned from doing a timeline retrospective.
I first got the idea of doing a timeline retrospective from the book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. The main idea behind timeline retrospectives is to add a dimension of time to the feedback that is gathered by having the post its in a timeline form. They talk about this very well in their book and I would suggest you grab a copy and hear about it from them rather than from me. The next paragraphs will be talking about how my team and I did it and the lessons we learned from it.
A quick backstory on the team before we begin. We’re a pretty young development team that has recently started working as a “scrum” (air quoting this because we’re not doing scrum by the book) team. We’ve completed two sprints which have been moderately successful. Most work committed has been delivered by our current definition of done and work that is undone is relatively minimal. Retrospectives have been splendid, the team has often come up with really good feedback both towards how they work together as a team and how we can improve the processes. Action items we’ve identified were acted on by the team and there was generally a positive feeling that we were improving as a team. During the retrospective of the second sprint I’ve noticed that the team has struggled to come up with more items to talk about and most of the items related only to the past few days of the sprint rather than the whole thing. That’s when I decided to switch things up.
Here’s our board
The team has given me their blessing to share this photo of the timeline board. We have an existing rule that any feedback that happens inside the retrospective cannot be shared unless the team has given permission to do so. Some things on the board have been redacted for privacy purposes
How did we do it?
We booked one meeting room with a whiteboard. On the board I drew a timeline with the date of the start of the sprint on the left most side and the end date of the sprint at the right most side. I placed a line at the middle of the board to mark the halfway point of the sprint. Since we worked on a 2 week sprint cycle, the line was to represent the dates between the first and second half of the sprint.
The team was then given two sets of post its, one blue and one orange. The instructions were simple, to write good things that happened on the blue post it and place it on which part of the timeline that thing happened. Orange was for the not good things that happened. They were allowed to write as many and as often as they’d like and were encouraged to write their thoughts even if they saw something similar on the board.
After our time box for writing and sticking was over we started to talk about the items we wrote down. At this point they were still allowed to add more items if the conversations jogged their memory. To add a bit of structure we separated the timeline into four sections based on which areas had the most amount of items on it. Those areas were the start of the sprint, the end of the first week, start of the second week and the end of the sprint. The team also identified (on their own) a key event that happened and that was when we closed our first story. We marked this as an important event in the timeline.
We went through each section and discussed the items on the post its. As we discussed we started noting down talking points that kept popping up from the discussions. These talking points would be the basis we’d use for coming up with action items later on. We also looked at the type of items we had per section. Did it consist of mostly blue items or orange items? This gave us a general sense of how we were feeling during those times and how our perception of how well things went changed over time.
After all sections have been discussed, we went back to the talking points and identified that a lot of our talking points had the same root problem. Our action item was then to try to solve that.
Things we learned:
- A lot of the things that went wrong happened towards the end of the first week and again towards the end of the sprint. The significance of this is those are the times when we were testing and reviewing our work; it was during those times where we’d uncover that we’d have different expectations of what a story was supposed to do. This exposed a gap in our process where we didn’t align our expectations.
- We didn’t close our first story until after a few days and this was the average time it took for us to do something. This meant that our feedback loop where we got feedback on our work was too big, so we didn’t know if we misunderstood something until a few days in.
- Another learning is that during the third section (the start of the second week of the sprint) people have found that they were working on several things at once. This is because we’d start working on something new then a previous item that was worked on doesn’t pass testing or review. This means that its sent back and they now have several things that are in progress. The importance of seeing this in the third section is that they realized that this was the time when they had just set a ticket for review or test and they started working on something new.
Adding a dimension of time to the retrospective provided some context to the items we discussed. It also allowed us to group our feedback to see which happened towards the same time and it made it more obvious to us what could have been causing this. All in all by doing this we uncovered a gap in our process and one that we’re working on to address.
All in all I wouldn’t suggest you do a timeline retrospective all the time but in certain situations having another way to do it might give some good insight.
Disclaimer: This was originally posted on my LinkedIn at https://www.linkedin.com/pulse/lessons-learned-from-doing-timeline-retrospective-jm-roxas