In Agile web development, your team breaks down its work cycles into a series of two-week sprints. In each sprint, your team aims to complete a series of “user stories,” referring to actions that a user will be able to successfully complete once the feature is added. While you can carefully plan your sprint to determine what features and bug fixes to prioritize within each sprint, projects don’t always go according to plan.
Regardless of how close you end up to completing your goals, it’s always worthwhile concluding each sprint session with a retrospective, which will give you better visibility into how your team works together and the challenges you face within the course of a project.
Here are some tips for holding a successful sprint retrospective:
Review every task that was completed.
Sit down with your team, then go through your sprint history and review every task that was marked as completed over the course of the sprint. Talk to the person responsible about it: Did it go as expected? What strategies were crucial to their success in completing it? They may be able to offer valuable insight to other colleagues who might work on such a task in the future.
Dig into the problem areas.
Along with exploring the keys to your success, it’s even more important to discuss areas where your team fell short of its goals. These conversations aren’t always easy, but it’s necessary to review issues that came up along the way so that you can learn from them.
For instance, if one task was estimated at 4 hours, why did it take 8 to complete? Avoid laying blame on any of your team members, but ask them to take a critical look at their own actions over the course of the project, so that all of you will be able to learn from their stories.
Ask team members for their feedback on what should or shouldn’t be part of the process.
Along with learning about what did happen in the sprint, it’s valuable to look at what your team members think should (or shouldn’t) happen during the course of the engagement. Get no-holds-barred accounts from your team regarding what they’d like to see happen in the next sprint, such as doing code inspections after completing a feature. And learn what they’d like to modify or stop, such as limiting the length of the daily stand-up meetings.
Pay attention to your communication process.
We often find that the majority of problems during a sprint come down to poor communication. That’s one area we look at deeply in our retrospective: Did a developer misinterpret what the product manager was asking for? Did the product manager fail to provide timely feedback when a developer was asking for help or clarification?
Focus on learning whether every team member felt comfortable that she or he was being heard, and that they were getting the insight and support they needed to be successful in the task at hand.
Write up an internal and external summary of what you’ve learned from the retrospective.
When concluding a sprint, your client or product manager will want to know the details about whether the sprint met its goals, and, if not, why not. Draw up a page of notes summarizing the highs and lows of the sprint, and what some of the roadblocks were.
When providing client- or business manager-facing notes, it’s okay to focus on a high-level summary—but it will also be helpful to write up a second set of more candid, warts-and-all notes that you can share within your team. Both sets of notes will serve as valuable documentation for their relevant audiences as the project progresses.
Use the outcome to optimize your processes.
Once you’ve taken the time to dig into your team’s experience of the sprint, you can use the insights you’ve gained to improve the process in notable ways going forward.
For example, during one sprint, we discovered that our development team was struggling to adapt to client feedback because it was coming in through a variety of formats—sometimes they’d send a Slack comment, sometimes they’d email, sometimes they’d call. This created a confusing and disassociated process that made it difficult for our team to build a cohesive vision for what they were trying to accomplish.
So, after realizing that the client feedback process wasn’t working, we built out a feedback template and began requiring that clients submit all of their feedback together in the template at the conclusion of each sprint. That’s provided us with a consistent format that ensures everyone’s on the same page, and serves us well to this day.
In order to build the best Agile workflow possible, it’s essential to continually examine your workflow and focus on how you can improve it, much like product development itself. By holding regular sprint retrospectives and learning about what each team member would like to see happen in the future, you’ll move closer to your ideal process with each sprint session.
