MeetingsData-driven sprint retros in the hybrid workplace

Naveen Kumar · 2021-10-14
Sprint Retrospective - Hatica

A sprint retrospective is a meeting held at the end of the sprint to reflect upon the tasks done during the sprint to determine which goals were achieved, which goals were blocked or stalled, and more importantly to diagnose the probable reasons for the blockers and challenges. They are an integral part of successfully completing a sprint and they play the role of providing insights into a sprint’s successes and challenges. 

Sprint discussions aren’t limited to tasks, but also include a discussion on the tools, processes, and workflows that the team uses. This, perhaps, is the unique signature of a sprint retrospective as everything is up for discussion with the aim of identifying inefficiencies and planning strategies to improve upcoming sprints. This aspect of the sprint retrospective is also referred to as continuous improvement.

In an effort to elicit feedback from team members and compile an actionable list of improvements for future sprints, teams commonly adopt a 3-question format:

  1. What went well during the sprint? 
  2. What didn’t go that well?
  3. What are some areas of improvement and/or what actionable steps can teams take to achieve better results?

These questions help managers to stay in sync with the overall progress of the team in addition to getting feedback directly from team members on how to improve processes in order to improve and better future sprints.

Importance of sprint retros in the hybrid workplace

While continuous improvement is the primary purpose of sprint retros, it can take on additional responsibilities in remote and hybrid teams.

Team cohesion is a crucial part of building and sustaining effective teams. As research shows, cohesive teams perform better, are more engaged, and have better team member well-being. Traditional ways of building cohesion that involve team members being co-located in a physical space cannot be used in the remote or hybrid workplace. However, a sprint retro can help glue distributed teams into a cohesive unit because of its nature of using open discussion and feedback. This form of open communication is designed to promote trust, transparency, and sustainable productivity – all of which aids in the team working together towards a shared goal, thereby promoting cohesion.

Sprint retros can also be effectively used to identify what processes are working, and what aren’t. Identifying the tools and processes that enable the team to perform optimally is crucial as these tools and processes form the foundations on which remote and hybrid teams are built. This process can either take the form of feedback provided by the team during the retrospective or as a follow-up activity post the retro, where the sprint’s activities are reviewed. This helps managers and leaders identify the challenges that teams face either in using the tools or in following the workflows or processes in place. Without a retrospective, these issues can go unnoticed for long periods of time and can have a negative impact on critical aspects such as effort allocation, project management, and even team cohesion. Thus, sprint retros are a critical process that ensures the seamless effectiveness and productivity of teams. 

Finally, sprint retros can also help identify tasks that might need additional people, resources, or time. This becomes ever so important in a remote or hybrid work environment where team members can work in silos where detection and resolvement of grave issues like burnout are much harder.

How to use data for better sprint retros?

Today, distributed teams are powered by the digital workplace where work is performed using tools like Google docs, Figma, or Github, and work activity and effort is tracked using other tools like Jira, ClickUp, or Asana. Insights from work analytics using the data exhaust from these tools can be a great source in helping managers and leaders understand team dynamics and how they work. 

Work analytics can add data-driven insights and factual understanding of the challenges faced during a sprint and can also help to identify the causes of blockers. This data encourages productive discussions towards finding long-term solutions. Here are some examples of how engineering teams can use work analytics data to run better sprint retrospectives: 

Cycle time

Cycle time, when measured over a sprint, provides visibility into different parts of the development cycle and the time taken to complete each step, thereby providing insights into the development velocity both for the team and for individuals. Cycle time helps shed light on the issues that might affect the different steps in the cycle, like large PR sizes that lead to more bugs, or harder and deprioritized reviews, or low engagement in the team, or even help identify the need to allocate more experienced staff to certain projects. To avoid such inefficiencies in the upcoming sprints, discussing the cycle time metric during a sprint’s retrospective is a must as it helps recognize and preempt risks to delivery or risks to employee experience.

How to use Cycle time metric in sprint retrospective

Effort allocation and workload balance

In the process of planning a sprint and allocating tasks amongst a team, there can be instances where some team members are being assigned a higher number of tasks, or tasks with higher difficulty. These higher workloads can impact the quality of work, time taken to complete tasks, engagement levels, etc. With such high levels of impact, effort allocation and workload balance become yet another item on the agenda for the retrospective. 

Feedback and discussion about these processes go a long way, but to get the complete picture and to identify the true inefficiencies in the planning and allocation processes, managers need to be equipped with factual data about effort allocation and workload management. Armed with this data, managers, and leaders can effectively plan upcoming sprints by allocating the right resources to the right tasks.

How to use Effort allocation metrics in sprint retrospective

Makers’ time 

Makers’ time is the dedicated slot of time that an engineer focuses on a task without context switching between tasks or other commitments. Common disturbances to makers’ time include meetings, messages, or notifications from work apps. These have a negative impact on the concentration and focus of the engineer as it can pull attention away from the task at hand and demand attention to something new. Going in and out of tasks frequently is shown to have adverse effects on one’s productivity and well-being. 

Managers and leaders have always relied on feedback and conversations from the retrospectives to tackle that lack of makers’ time in their teams. Augmenting sprint retrospectives with work analytics means managers can combine qualitative feedback with data to identify the real reasons for the low makers’ time and devise effective strategies to boost makers’ time for individuals in their teams in the upcoming sprints.

How to use Makers time metric in sprint retrospective

Combat conflicting feedback 

Although sprint retros can be a safe place for transparent feedback and conversations, a common risk is that the conversations might sometimes create misunderstandings amongst team members. Additionally, conflicting feedback might also be difficult to handle in distributed teams. Both situations pose a risk to team cohesion. On the other hand, there is a concern that there can be less feedback and communication from team members perhaps because teammates might be holding back comments in order to avoid conflicts. Such situations can lead to crucial information going unspoken.

Managers also have the job of tracking all the feedback, in addition to handling opposing viewpoints and conflicts and taking notes and forming opinions of their own. This can sometimes overload managers making it hard to prepare the next steps and leaves room for more inefficiencies and biases to crop in. 

Most of these challenges can be effectively combatted using work analytics where true issues and inefficiencies can be identified and investigated upon using quantitative evidence and data viewpoints, helping the efficiency of the team. 

💡 Hatica is a work analytics platform that equips engineering leaders with a factual, holistic and unbiased understanding of their dev team’s work activity. 

Dedicated dev dashboards for development velocity and throughput along with communication and collaboration analytics, workload planning, effort alignment dashboards, etc., add much-needed context and data to sprint retros by making them data-driven and promoting continuous improvement.

Subscribe to Hatica's blog

Get bi-weekly emails with the latest from Hatica's blog

Share this article: