Risks and problems of Scrum projects and teams

Scrum is a simple framework for developing products with business value. However, working with Scrum is not easy for inexperienced teams.

The Scrum Master role must have the most experience with Scrum to deal with all the problems and risks around.

In this article, I share some examples of risks and problems of Scrum teams. Source: Reference: “Scrum Master explains the roles to colleagues in the Scrum project“,

Vague communication or lack of such

Difficulty in ‘translating’ the description of the required product or functionality from the business into technical functionality – in technical language.

Each group speaks ‘their language’ without the groups being able to understand each other. Unclear or inaccurate specification and hence – divergence of expectations of the business and the final developed product. Reference: “Why do you want to be a Scrum Master?“,

Responsible: The entire Scrum team with business representatives and end-users

Strategy: Organizing workshops to help unify the language. Clarifying terms, understanding business requirements (this is a two-way process, it’s not just the development team telling others what things are called.

Finding good practices in the description of specifications – so that things are clear, written understandably and understandably. both sides language. Reference: “Scrum and Kanban: similarities and differences“,

Maintenance and updating of project accompanying documentation – lack of time

A new team, unaccustomed to the technologies used (eg version control, continuous integration – how this works).

Additional description is required through instructions and countless accompanying documentation, which must be updated with each change in code or mode of operation – because the team is not used to working with the chosen technology and can not get the necessary information from there. Reference: “Preparation for the Certified Scrum Master exam (PSM, CSM, BVOSM)“,

He can’t orient himself or doesn’t trust himself. Development time is used to update documentation.

Responsible: Development team

Strategy: Training sessions and finding good practices for sharing news – so that everyone understands and understands in time.

Possibly courses and additional qualifications of the participants (after agreement with the Product Owner and the people responsible for human resources and development). Reference: “Scrum Master instead of project manager“,

Objective examination – possibly by a person with experience, the documentation and screening only the necessary documentation, so that the team does not waste time with unnecessary things. Eventually, a change in technology if things are so complex that they do not meet the qualifications of employees. Reference: “The differences between Scrum and Kanban methods of working in Agile projects“,

Last-minute changes

Problem accompanying the first problem in the leaves. The business does not agree or does not understand what the development team has understood and there is a discrepancy in expectations.

The increment is wrong or unusable and needs to be fixed in the current sprint due to missing business deadlines.

The business is reluctant to procrastinate and give the team time to correct mistakes in a subsequent sprint. Reference: “Why apply Scrum to your company projects“,

Responsible: Product Owner and Scrum Master together with business representatives – the less, the better

Strategy: ‘Note to’ the less, the better ‘: the problem should be discussed openly, but ONLY with the right people, not everyone, just to give an opinion, without really understanding or are directly dependent on this. Reference: “Why do you want to be a Scrum Master?“,

This is an unnecessary blurring of focus. Meetings only with those precisely chosen, people who are directly responsible for what is delivered in each increment.

An open conversation between them and the Product Owner – The Product Owner is the one who records these requirements and transmits and explains them to the development team. Reference: “Working on projects with Scrum and Kanban“,

Exchange of information and clarification and crystallization of specifications after the team has learned to understand each other and speak the same language.

The last sentence that the business is reluctant to procrastinate – this is normal, procrastination is a waste of time and money and no business seeks to do so, but businesses need to know who they are working with – especially if the development team is a beginner, things will not happen that way as fast and true as if people are senior professionals with years of experience and insight into things. Reference: “Scrum framework: Questions and Answers“,

Product Owner must be ‘strong’ and able to understand both the needs of the business and share the problems of the development team.

Impossibility to achieve a sprint goal due to changes in product requirements

Problem-related to the ‘face’ of the Scrum team to senior management. A clear answer to the question What will you develop in this sprint?

Cannot be given because the team knows that the agreed and described sprint goal is inaccurate or impossible (because they know the people they work with and know they will change their requirements. subsequently) and will force them to do the job anyway. Reference: “Sprint Review event in Scrum with examples“,

The team feels pressured by these factors, and management is too weak to acknowledge the problem.

Responsible: Scrum Master and Product Owner, subsequent involvement of senior management if necessary. Reference:

Strategy: “I am aware that the sprint goal is something that many Scrum teams do not write about and do not spend much time and resources on, but let’s say it is something that is a must in this organization.

It is a good thing. the team to know what it is striving for.
The described problem speaks again of unclear communication, which leads to errors and delays in the project. Reference:

This is a weakness that needs to be addressed from the outset. If the business constantly pulls the bone to itself without the Product Owner interfering, the problem will never be solved.

The Product Owner is the one who should actively intervene in this problem – he is the person in the organization who depends on what and how it will be delivered.

He is directly responsible for quality and quantity. If it is the practice of the organization to ‘caress’ the business, then the employees in the organization will be constantly under stress, knowing that nothing depends on their opinion and problems.

The Scrum Master should also intervene here – Scrum Master strives to have a good atmosphere at work and people do not feel constantly trampled and stressed because someone from above is pulling for something.

The Scrum Master should take the matter to the Product Owner and reassure him that this is something that depends on the work, the quality, and ultimately who will stay at work (people leave because of such problems) and who will not.

From here, we can now involve senior management – with the question of why it allows businesses to ‘arbitrarily’. There must be loyalty and mutual understanding on all sides.

There is a lot of work and there is always work to be done, but good planning must be done according to the needs and capabilities of each of the parties involved to avoid losing staff in the end.

Product vision

Uncertainty in the development plan and product vision. Business does not know what it wants.

Responsible: Business Representatives and Product Owner

Strategy: The active party here is business. It is the business that pays to develop a product, and in the absence of a vision, it will simply spend its money without a clear idea of ​​what it will end up with.

A visionless business means that the team that will develop the product must either be very highly qualified (to compensate for constant changes without greatly affecting the release plan and quality) or simply be a team that does not sleep.

The second is, of course, frivolous if the organization cares about its employees (not sleeping is equivalent to ‘I’m leaving soon’).

Business relationships with such a customer are doomed to failure – both the end product and the relationship with product suppliers.

Lack of authority

If Scrum Master is ‘too young’ or looks inexperienced or insecure, no one will listen.

He will have to unite the team and explain values ​​to them and offer or seek solutions, but if the team is only senior and very experienced, no one will pay much attention to what Scrum Master says. Sexism, to some extent – she is a woman, she is young and inexperienced, why she came to teach me.

For your team to believe in something, you must first believe in yourself

Directed by me to me. Personal qualities, soft skills. Temperament. To learn to convince the team, to learn to present my ideas clearly and ‘contagiously’.

Personal Vs. official relations

After all the lectures, I still think that Scrum Master is a person who is part of the team – maybe the person who should be closest to those who do the work.

However, things can easily turn into purely interpersonal relationships, and people are still there to do work, not make friends. Scrum Master is your closest person, but he also has some powers (maybe over you), he can also give you orders, so he is not always your ‘friend’.

Things get a little blurry and in theory, everything is very utopian and cohesive. The border is quite thin.

Unclear practices

A lot of things are very clearly described in the bagpipe – how exactly it happens and what should and should not be done.

However, there is a hell of a lot of things that are not specified and depend on the personal interpretation of the one who reads them.

You can’t go out in front of your team and say, ‘We’re going to do this because I think it’s good,’ without really having a clear argument for why. It is a matter of experience.

You always risk having someone say this is not written anywhere and undermining even the little authority you have

Know your team

Know what kind of people you work with. Everyone has their flaws and things they are used to.

However, not everything should become a problem.

You need to be able to know how to approach ‘more special’ people without risking either their own or your position. This should be done professionally so that things do not become friends.

Be specific in your speech and actions, finish what you started

Don’t leave things open. He does not lead vain discussions. Conducts effective meetings, meetings with a clear conclusion.

Meetings in which we clarify our problems are a good thing, but meetings in which we discuss how to deal with problems are even better.

The teacher who is still learning

SM must be a teacher for others. To explain practices to them and to involve and engage them.

However, Scrum Master does not always know and can do anything. Scrum Master with many years of experience can be in a funny or unpleasant situation if he gets into a new team.

Take criticism, learn. Listen to what is being said, understand. Understand quiet reactions. Ask the right questions if you want ‘right’ answers.

Follow up

If the problem has been discussed and something has been decided or agreed upon, go back and ask if the problem still does not exist.

The fact that the topic is closed does not mean that the problem has disappeared.

Planning the work during the day

take 10 minutes each day to make a plan for the day and remember what meetings you will be attending (and whether you have prepared for them). What to do, what to leave for tomorrow. Be organized.


Be tolerant, this is part of your professionalism. We all have problems, but it’s just work. Listen and don’t order. People appreciate when others are patient with them (but don’t be idiotically patient, deadlines are deadlines)


Discussions often overlap, but time is short. You need to be able to stop and bring everyone back to what you came together for.

Is the Sprint retrospective important?

Some will want a flashback, others will say they want to use their time more efficiently because they know they have a hell of a lot of work to do. You need to convince them that flashbacks are something we all benefit from.

Then I hadn’t slept and said something stupid

A remark from a member of the team about a strange reaction to a previous meeting, which I thought should be discussed as a problem. Yes, it may not be a problem, but why not be clear that it was not a problem? I can make him avoid reacting next time so that we don’t all laugh.

By Robert Brown

Robert Brown is a longtime manager of a technology organization and author of a management book. In his spare time, Mr. Brown helps students get a better education by helping to publish free study materials.

Leave a Reply

Your email address will not be published.