Introduction

 

Many teams working in software development claim that they work in SCRUM methodology. It often turns out that this is not entirely the case. They use some of the scrum guidelines, but to be able to say that you work in SCRUM, you have to follow things that are unchanging in a scrum. When choosing a team to work on your application, can you be sure that the team is using the SCRUM framework correctly and in line with best practices?

Here is a list of signs that may indicate that something is not as it should be with SCRUM.

More than one product backlog

 

The product backlog is the bag in which we put all the requirements, tasks, and user stories. Why is the backlog created? So that the team knows about the short and long-term requirements for the product, it is developing. From the product backlog, things are selected for implementation in subsequent sprints. If the product has several backlogs – e.g., one in Jira, the other in Trello, it means that planning work in the next sprint will take more time, and probably the team will not be sure of planning well done. If the team proposes to use more than one backlog, it means that they have no experience working in SCRUM.

There are no acceptance criteria for tasks that are in the sprint backlog

This is a dangerous situation in which the team may not know when they may think that the job has been completed correctly. Most often, the content of the task tells what to do. The team suggests HOW it should be done. The acceptance criteria answer the question – WHEN we can conclude that the task has been completed correctly? Without acceptance criteria, often, the effect is not what the product owner expected.

Definition of Done

 

The term Definition of Done is very often confused with acceptance criteria. The purpose of the definition of done is to determine when a task performed during a sprint can be moved to the DONE column.

Example definition of done:

1. The developer has completed the task and checked that the solution meets all acceptance criteria

2. A code review has been carried out

3. The acceptance criteria have been automated and included in the continuous integration process

4. The change has been uploaded to the staging environment

5. The automated test has been appropriately performed on the staging environment

The definition of done is set for ALL tasks that are carried out in a sprint.

Lack of definition of done usually means that the team recognizes that the task was completed when the developer seems to be working for me.

Misunderstanding task estimation

How many hours is one story point? Maybe we better estimate in hours? The goal of estimating tasks that hit the sprint backlog is the same understanding of the effort needed to accomplish the task by each team member. This does not mean that the task will be carried out by each of them at the same time. Differences in implementation result from professional experience, domain knowledge, etc.

However, the effort needed to complete the task must understand the same for every team member. Only then will you be sure that everyone understands how the task is done similarly. Therefore, it is dangerous to estimate in hours – in particular, how will senior developers estimate them and during mid-sprint implements them mid or junior…

No DSs taking place

Daily Scrum (Daily standups) allows you to synchronize the work of everyone on the team. This is the moment when the team’s goal is to FIND if there is a threat to the SPRINT goal and if mutual help is needed. This is a mini-planning session to optimize the team’s work on the next development day.

DS’s goal is not to confess to every person what she did yesterday … Without DSs taking place risks – a person from the team has a problem with the task, but is ashamed to ask others for help – a person from the team does what other than it should… – The team doesn’t integrate. It is better to spend 10-15 minutes a day synchronizing than three days for unnecessary code refactoring.

Lack of planning and compliance with fixed sprint time intervals

A sprint that lasts until all tasks are completed is a scratch anti-patter.

If we are unable to complete all planned tasks in the sprint, there is something that can be improved. That is why a retrospective was invented in SCRUM, during which we should discuss the problem and try to do better the next time. It is no shame that the sprint could not be completed.

Lack of understanding of the meaning of the flashback

What is a flashback for? This is an event during which we answer the following questions:

1. What was good at bands in the previous sprint?

2. Why was that good?

3. How can we do it even better in the future?

We also discuss challenges:

1. What was problematic during the sprint?

2. What was the source of the problem?

3. What should we do to change it in the future?

ENTERING LIFE CHANGES is the key.

We’re making a list of the tasks we’re working on as a team. We open the next retrospective by summarizing the status of completed tasks from the previous one.

Thanks to this, with the flash, appropriately done, we make the team work better and better with each sprint worked.

Bad review

Often, it seems to the teams that review is used to show stakeholders the product demo the team is working on. This is one element of the review, but the goal is something completely different. During the review, we want stakeholders to see where the team is currently and to set goals and priorities that the team should focus on in future sprints. This is the moment when business and technical persons synchronize their knowledge and needs. Thanks to this, the team avoids the situation in which, in subsequent sprints, they will work on things that will not add value.

Poor planning

What is planning for? To plan work ON ANOTHER SPRINT. When planning, the team should answer the question about the purpose of the sprint. Then, together with the product manager, he should choose the tasks that currently bring the most significant business value. The business value should result from current business goals defined, e.g., for the quarter.

The tasks that we transfer to the sprint should have defined acceptance criteria, which I discussed earlier. The same estimation – I suggest using story points. If your team does not estimate the tasks performed within the sprint, then there is a high probability that the sprint goal will not be achieved.

From the perspective of many sprints, poorly executed planning reduces the motivation and commitment of team members.

Summary

 

I hope that at least a little easier for you in diagnosing problems of misuse of the scrum. If you have any questions, please contact me.

Visit my YouTube channel for more SCRUM materials!