Feature Retrospectives
The why, how and what of the agile retrospective
In this post, I’ll share with you why you should want your team to perform retrospectives. I’ll explain how to do it in a way that will make its benefits shine and I’ll provide a short template to get you started easily.
- Part 1: Why should you do it?
- Part 2: How to add Feature Retrospectives to your existing development process?
- Part 3: What do you do in the Feature Retrospective meeting? Who do you invite?
- Part 4: Feature Retrospective template
- Part 5: Summary
Part 1: Why should you do it?
Let’s start with the Why (That’s always a good idea, Thanks Simon Sinek). We all know that the dev process is always longer than we would all like it to be. So why should you add another step to it? What’s in it for you?
Let me explain why it’s so important.
The motive of the agile retrospective is to constantly improve as a team.
This is our way to regularly take small steps of improvement. These small steps would create a culture of growth and increase our productivity in the entire development team. We want to have a “Retrospective Culture”, in which people constantly want to learn and do things better; faster, with less effort, with less mistakes, with less resources, etc. Small (seemingly insignificant) improvements, when done consistently over time, lead to STUNNING results (Robin Sharma)
I hope you’re now convinced that retrospectives are a good idea.
Let’s learn how to lead the team to having a “Retrospective Culture”.
Part 2: How to add Feature Retrospectives to your existing development process?
Here’s the gist of it:
- Have a feature owner for each feature. This is the person responsible for the overall delivery and execution of the feature — end-to-end from ideation phase to the full rollout.
- Have a slack channel per feature — this allows all communication to happen in a single place where all stake holders can follow. It’s beneficial for the organizational memory, and it helps remembering who made the decisions and more importantly- remember WHY those decisions were made and which considerations were taken into account when making them.
- Create a Feature Retrospective document for each feature — use a template (I’ve added one at the end of this blog)
- Conduct the Feature Retro meeting
- Share with the group
Where does this fit in the existing development process?
Our dev process used to look like this before we added feature retrospectives:
I’ll first explain every step of the above diagram. Then I’ll explain what changed in that process to support the “Retrospective Culture”.
- Step 1: “Product Planning” — the product manager plans the feature(the dream).
- Step 2: Open a Slack channel for the feature, to keep all communication about it in a single place.
Dominic Kent]
- Step 3: Have a “Feature Kickoff” meeting, where the product manager explains about the feature to all developers before they start to work on the feature.
- Step 4: Review the spec of the feature (what are the requirements?). This is a prerequisite needed in order for the developer to prepare the design of the feature.
- Step 5: Prepare the feature’s design and do a Design Review meeting (This can be another blog post just by itself)
- Step 6: Estimate the feature’s timeline — when will it be ready? which milestones will we have? We also have a Poker Planning meeting, where we go over the tasks together and evaluate how long each of them would take. There are multiple free online tools to do that, here’s one. This reduces the risk of the task not being ready on time since it allows more people to see the plan and think about what can go wrong and what we forgot to take into account.
- Step 7: This is the main dish — Feature Development — this is when you actually get to write the code.
- Step 8: QA (Optional)— once the feature is done, we have a QA that tests it.
- Step 9: Rollout meeting — how do we plan to release the feature? For example open the feature first to a small group of users and then increase traffic gradually till it’s open to 100% of the users worldwide. Consider everything that can go wrong, plan how will you know about it, and how will you solve it in case it does (closing a feature toggle, rolling back, etc.)
How did we change the existing process?
We added 4 more steps:
1. Before you start:
- Define who the feature owner is.
- The feature owner should open the dedicated Slack channel for the feature.
- The feature owner should schedule sync meetings in a suitable frequency.
- The feature owner should create a new feature retrospective document using the template. Store it in a place where it’s visible, where you could easily add more feature retrospectives in the future. For example, on Confluence or a shared drive.
2. During the development process:
- Each team member should gather individual insights, and write them down in the feature retro doc.
3. Once the feature is out:
- Conduct a Feature Retrospective meeting with the feature’s team
4. Share your conclusions
Share your conclusions with the rest of the R&D so everybody could learn from it. This is the cherry 🍒 in the top of the whole process. Do not skip it! You could share it in an email, in a meeting, or even on your team’s slack channel. Sharing is caring!
Part 3: What do you do in the Feature Retrospective meeting?
Create the right atmosphere for discussion
- Don’t make it personal, don’t take it personally
- Listen with an open mind
- Everyone’s experience is valid
- Focus on improvement, rather than placing blame
What should we talk about in the meeting?
- What did we do well?
- What can we do better next time? It’s important to phrase this question in a positive way. Don’t ask “What did we do wrong?”, assume people had best intentions, they did the best they could given the time and knowledge that they had at the time.
- Did we evaluate time estimates correctly?
And then:
- Group similar issues together, find ideas about how to do it differently and better on the next feature, discuss each issue briefly as a team.
- Define action items, open tickets (on your task management tool like Jira/Monday/Asana) + assign them + set deadline dates.
Who’s invited to the meeting?
Whoever took part in the feature, could be Backend and Frontend developers, QA, product managers, User Experience experts, content writers, Analysts, etc.
Who else?
You could add a moderator who is a neutral person that leads the discussion, asks guiding questions, gives the brief and directs the discussion into a positive constructive conversation.
Every feature should have a Feature Retrospective
To make it easy, here’s a template you can use:
Part 4: Feature Retrospective Template:
- Feature description: a few lines explaining why it’s needed, what is it about
- The team: name the people who work on this feature: product manager, front end developer, backend developer, QA, etc. Whoever took part!
- What did we do well? What can we do better next time? Think about the API, time estimations, management, team work, sync meetings
- Action Items: Write what needs to be done, assign it to the relevant people, set the due date to the task. if you’re working with Jira/Asana/Monday/ any other task management system — add it there. Don’t leave it in the doc.
5. Summary
We went over why you should conduct Feature Retrospectives, how do you add it to your existing development process and what should the retro meeting look like.
Feature Retrospectives are an important part of the dev culture.
When done right, It should provide the team with a nice warm feeling of a sweet closure to the feature that is done, and plenty of motivation to move on to the next feature with aspiration to implement the new ideas and improve the next time around.
As the famous philosopher Sophocles put it;
“I have no desire to suffer twice, in reality and then in retrospect.”
― Sophocles, Oedipus Rex
Feel free commenting and asking questions!
