Select Page

Scrum, but…

The term “Scrumbut” is now often used to refer to incorrect understanding or intended modification of Scrum rules. Scrumbuts are reasons why teams can’t take full advantage of Scrum to realize the full benefits of agile product development, along with the solutions that teams implemented instead of using Scrum practices.

A typical Scrumbut formula looks like this:

<We use Scrum, but> <we have these unique circumstances> <so we have had to modify Scrum so it works here>

Or, in a shorter format:

<Scrum, but><reason><workaround>

Often, circumstances create blockers for the team on their way of adopting Scrum practices. Quite often these blockers cannot be removed for a reason, and that is where Scrumbuts are created. These blockers can be both internal and external. Internal blocker would describe something that comes from lack of understanding of how Scrum should work, or lack of will, or power to change internal processes and/or approaches and remove blockers. External blockers are organization-wide practices, structure, beliefs, and processes, that the team is dependent on, especially in the early stages of transition or resulting from lack of understanding of Agile and Scrum practices by management of an organization.

A workaround is a way of ignoring or altering certain Scrum practices as a result of a blocker. Alternatively, it can be described as a way of focusing on symptoms rather than on reasons that are causing an “organizational disease.”

Common examples of Scrumbuts look like this:

–       We have Scrum, but we not always can have all the work done within a sprint, so we extend sprint’s length.

–       We have Scrum, but we have too many stakeholders, so we do not conduct Sprint Review meetings

–       We have Scrum, but we are understaffed, so we have developers participating in multiple teams

We should not confuse Scrumbuts to organic evolutionary steps that a team would undertake on the way of becoming a mature scrum team, therefore the term shouldn’t be overused.

However, Scrumbuts in an established team most likely originate from the lack of understanding of agile development practices or Scrum framework by either the team itself or higher management. It is easy to check if this is the case by simply asking a team to provide a reason of adopting this modification to Scrum practices. It is not that often when this reason turns out to be a valid one.

For example, if you don’t have code reviews, pair programming, or team members are specializing in certain areas of the product, perhaps you’re simply in the very beginning of your Scrum journey. On the other hand, if the same applies to mature teams, the real reason behind it can be anything from inability to sell the concept to the management, to inability to implement the framework properly and benefit from it.

Dealing with Scrumbuts is one of the most important tasks that a Scrum Master should facilitate. However, do not forget that continuous improvement is a responsibility of the entire team and cannot be tasked to the Scrum Master only.

Here is a list of common blockers and workarounds that many teams are implementing around the world. All projects are different, and for some these Scrumbuts can be justified. However, this list can be used as an agile health check and a way to discover such workarounds within your teams.

If anything from this list corresponds to your current practices, ask yourself why did you adopt such a practice and is there a way to improve related processes?



1.    Scrum Team doesn’t own or manage its development process

2.    The team doesn’t focus on continuous improvement of their processes

3.    Team fails to follow an established action plan to improve performance

4.    There is no available list of team problems, as well as improvement plan

5.    There is no time or budget allocated for solving problems

6.    Sprints are getting extended or shortened

7.    Sprint length often changes from one sprint to another

8.    Work within sprint goes in phases (water-scrum-fall)

9.    Team works overtime to achieve sprint goal or complete all the stories on a regular basis

10. Work doesn’t have a constant rhythm, there are pauses between sprints

11. Absence of common understanding of a workflow within the team

12. Extra work is frequently added to the sprint

13. There is no designated support team or there is no allocated time for application support for the Scrum Team

14. Selected tools determine process (Jira, VSTS, etc.)

15. Some of the Scrum ceremonies are not happening on regular basis


16. Product vision, release vision, and sprint goals are not clear to the Scrum Team

17. Sprint Goals are not corrected based on shareholders’ or users’ feedback

18. Backlog contains descriptions of solutions

19. Value of PBIs cannot be clearly understood from the backlog


20. Team hasn’t established Definition of Done, or it is not clear for team members

21. Absence, or rare use of agile development practices, such as CI, Code Review, Refactoring, TDD, etc.

22. Lack of testing by developers; High volume of bugs discovered in QA / UAT

23. QA activities are happening in separate sprints from development

24. Lack of automated tests


25. PO is not working with / hard to reach by the team during the sprint

25.1 Po is a client’s representative, working on client’s side

26. PO doesn’t have time to work with all the assigned teams

27. PO is not making product-related decisions (What needs to be developed and in what order)

28. Teams have multiple POs

29. POs prioritization isn’t based on business value

30. PO tries to get all the features done ignoring Pareto Principle (80/20 rule, 80% of profits are coming from 20% of feaures)

31. PO is a boss of the Scrum Team

32. PO is not invited to Sprint Retrospective

33. PO doesn’t know key stakeholders and clients

34. PO doesn’t provide feedback to the team

35. PO dictates how solutions should be built


36. Scrum Master’s work is performed by one of the Developers or a PO

37. Scrum Master changes every sprint

38. Scrum Master is not located next to the team

39. Scrum Master lacks soft skills to effectively work with people

40. Scrum Master lacks courage to disagree with team’s decisions that contradict Agile / Scrum principles and values

41. Scrum Master dictates how solutions should be built

42. Scrum Master performs POs work

43. There is 1 Scrum Master for more than 3 — 4 teams


44. No common goal (for product, release, sprint)

45. There is no sense of shared responsibility for completion of sprint goals

46. Team members have their areas of responsibility without understanding of work outside of their area

47. Development team is divided into sub-teams, taking care of separate components or focusing on separate horizontal layers

48. Team members change throughout the sprint

49. Team members are working on other projects in parallel

50. Team members are appreciated / penalized on individual basis

51. Team doesn’t have enough skillset to complete all the work on their own


52. Daily Standups are not happening on regular basis or start later than planned

53. Daily Standups are conducted at the team members’ desks

54. Development Team reports their progress to SM or PO on Daily Standups

55. There are discussions on Technical or Business solutions happening during daily Standups

56. Daily Standups are taking longer than 15 minutes

57. Daily Standups are not in the same room

58. If working as a remote team, daily standups are happening separately based on location of team members

59. The team is getting interrupted by others during team meetings

60. Team members are using gadgets during the team meetings

61. Team works on PBIs without taking items’ priority into consideration


62. Team doesn’t work with the Product Backlog prior to the planning meeting (Grooming, Refinement, etc.)

63. Team commits to delivering Sprint Backlog rather than to the Sprint Goal

64. Team agrees on who would be working on which tasks during the sprint

65. The work that was not completed in the sprint is automatically transferred to the next sprint

66. Too many changes are happening within a sprint

67. Team overcommits on a regular basis so there is always some incomplete work at the end of the sprint

68. Not all the team members actively participating in planning, estimating, designing a story

69. Not every team member knows what needs to be done under every user story taken to the sprint

70. User stories in sprint backlog are often massive. Team fails to split these user stories.

71. User Stories are broken down by horizontal layer, or by screen, without taking business value behind the story into account


72. No tracking of successful and unsuccessful sprints

73. Sprint is considered to be unsuccessful if Sprint Backlog is not fully cleared, without taking Sprint Goal into consideration

74. Stories are considered done even if there are unresolved bugs in them

75. Demo is happening without structure

76. Development team is not participating in the Sprint Review

77. Stakeholders’ feedback is not collected during the Sprint review


78. Team is looking for certain team members to blame for failing the sprint

79. There is no action plan generated at the end of the Retrospective meeting

80. Retrospectives are always following the same scenario

81. Problems are identified, action plan is created, but team never follows it

82. There are no metrics to measure performance


83. There is a manager of the project responsible for successful implementation of the project

84. Managements doesn’t understand the nature of team estimates and requires to “stick to the promise” without taking into consideration if team achieved the Sprint Goal or not

85. There are development managers, scrum managers, release managers, and other sorts of managers, responsible for part of the work

86. Managers are using team artifacts or velocity to measure team’s performance

87. Managers are using Scrum Master as a leverage to increase team’s speed

88. Scrum is imposed by management, without understanding of agile values and principles


89. No convenient ways of communication with remote team members

90. No convenient rooms for team meetings

91. Cubicle-type office, teams are separated or not sitting together

92. Inconvenient workplace to work in pairs

I am surprised if you made it to here! And as you made it this far, here’s another important piece of information about ScrumButs:

–       There is nothing wrong about having a positive ScrumBut

This goes with a condition. And the condition is that the existing ScrumBut must be the most logical solution suiting a particular team or a project. Solution that maximizes efficiency of the team.

This means that if the “unique circumstances” we’re referring to can be adjusted, we should follow Scrum practices, rather than alter them to fit the environment. If circumstances can only be addressed with a Scrumbut, a team can agree to follow this practice. After modification to the process is made, a change in performance should be also measured. If ScrumBut brings productivity down — it is a negative ScrumBut and must be avoided!

At the same time, if a mature team follows the Scrum framework, but feels like certain Scrum practice is not efficient and can be modified to improve efficiency, they may try incorporating a Scrumbut. Changes caused by every workaround should be measured.

Scrum is a well-established framework, but it should not be followed blindly. What works for one team may not be applicable to the other. That’s why my advice for all the Scrum teams is to implement Scrum to its best, and then adjust it with ScrumButs as needed. Any time you have to assess the chosen methodology remember: “Individuals and interactions over processes and tools”.