The most common mistakes of Sprint Retrospective

[#1]

Along with adopting the Agile methodology, there come some principles that Agile methodology is using. They were established, not to be avoided or ignored as someone can think.

Using these rules is a desirable practice and guarantees success in the project. This seems to be something easy to introduce into your everyday work life. Is it though?

One of the Scrum’s events is a Sprint Retrospective. Quoting Scrum Guide: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint”. The main purpose of Sprint Retrospective is to figure out what went well during the particular time, what could be corrected, what the team will do to improve the project and to achieve better results in the next Retrospective.

Having in mind the above, let’s take a look at some common mistakes that frequently occur during Retrospectives.

Irregular or skipped Retrospectives

The most common mistake that shouldn’t even be considered possible is avoiding or postponing a Retrospective. Scrum rules state that during Retrospective, the team tries to evaluate their performance by both, pointing out all the things that went well, and listing the areas requiring improvement. This kind of introspective activity allows the team to come up with valuable ideas for enhancing their efforts in the following Sprint, until the next Retrospective and revisiting the changes once again.

Establishing a ground for the forthcoming discussion is the foundation for creating a trustful workspace. Cultivating honest conversations about the direction a project is heading also helps to organize the work better and is, therefore, a beneficial habit.

Each Retrospective requires the team to polish the development process to make it more effective and friendly for all team members.

To summarize – what would be the result of not having regular Retrospective meetings?

Besides professional aspects, all meetings have one more value- they are integrating the team!

Retrospective? Oooh, it does not concern me.

There is a widespread belief that not all team members have to participate in these regular meetings, which is basically wrong. The intention of the Retrospective is to spotlight all types of impediments in every project area,  including actions connected to this process. That is why participating in the Retrospectives should be required from everyone. Moreover, it is not just about plain participation. Team members should make and communicate observations on every step of creating software regardless of their role in the project.

Everyone has their own experience and unique perspective, so it is important to share it with the rest of the team. If the whole team isn’t be involved in the Retrospective, there is a high probability to omit some basic-level issues or skip an important point of view. Over time, this can even cause project failure.

Ignoring improvements

The Retrospective purpose is to “Inspect how the last Sprint went with regards to people, relationships, process, and tools; Identify and order the major items that went well and potential improvements; Create a plan for implementing improvements to the way the Scrum Team does its work”. In general, the meeting serves to provide sometimes new, sometimes only improved work practices to gather the best results.

On the Retrospective, every member of the team is actively taking part in the discussion, and in creating a plan for the next steps in the project. These meetings sometimes take 3 hours, so it would be such a waste of time not to take into account Retrospectives’ output and not to try implementing the best ideas. “Improving” means to do something in a better way. It means to finish tasks, achieve great results while constantly looking for the opportunity to adopt even more effective practices.

Thus, if some improvements established and accepted by the team seem to be suitable and valuable for the project, it isn’t reasonable to neglect them. Since then, team members' duty is to do their best to make the project successful, by embracing the change suggestions that come from the Retrospective meetings.

Ignoring blockers

During the discussion, the team is able to find out which of the previous tasks were blockers or which ones turned out to be difficult to complete. How can we find those painful tasks? The easiest way is to verify which of them were in progress for the longest period. The second possible indicator of a tricky task is the fact that it still hasn’t been resolved. And the third one – if the ticket has been reassigned several times to several people it may mean that the task to solve wasn’t all that clear and simple. The good idea is to discuss, for example, 3-5 of the problematic tickets, and try to find a way to improve processes or techniques directed for solving troublesome situations.

At this point, among many apps in Jira, the Agile Dashboard for Project Management can be very helpful. It can for example list out problematic tickets in the project. The Problematic Tickets feature displays faulty issues in the project. Using it enables you to see through the issues that don’t meet quality criteria and quickly fix the most burning ones.

Problematic tickets are considered faulty because of an eg. long time since the last update, the ticket wasn’t closed in 1 sprint, past the due date, etc.

Moreover, if you want to check which of the tasks took the longest time among all tickets in the project, you can do so by tracking the time logged in issues with Worklogs - Time Tracking and Reports.

This add-on will allow you to easily track the time being spent by the members of your team in a given period. The app allows grouping data by days, weeks, months or years. Moreover, you can also categorize entries by projects and use several filtering options.

Using tools whose purpose is to simplify your work and project managing should be obligatory or at least strongly advised.

Not providing Action Items

During the lively discussion, some of the ideas may emerge simultaneously which makes it easy to lose some of the bright thoughts in the course of conversation. What can we do not to let them fade away along with the end of a Retrospective? Use Action Items! This is the simplest way to remember new tasks or improvements to current issues. Moreover, Action Items have some really useful features like assigning the task directly to the team member or specifying the deadline for the selected Action Item. The appointed project participant will receive a notification, which won’t let him forget about the assigned task.

A helpful tool- Confluence. Its functionalities allow creating action items in a really simple way! How to find them?

Eg. In meeting notes sheet:

Just write the "@" symbol to assign the action item to someone from the team.

You can use this tip everywhere in Jira as well.

How easy! How useful!

Not emphasizing the positive stuff

At every work, there are good times and these worse as well. In general, employees and employers are focused on fixing all the issues appearing during the work. Of course, this is the way to make the project succeed. But is a man really alive only with bad things? The good practice is to celebrate both smaller and bigger achievements.

Such actions have several pros:

* they motivate,

* they raise the team’s morale, *

they integrate the team,

*they make the atmosphere more friendly,

*they relax/loosen the atmosphere in the project,

*they make employees happier,

* they make employees know that their job is visible- they can see the effects of their works etc.

Of course, frequent and big parties can turn above points to the opposite, but when the team is going with common sense, everything should be great. So, do the celebration of successes!

A little party never killed nobody 😉