Scrum But. According to Scrum.org, “Scrum Buts means that Scrum has exposed a dysfunction that contributes to the problem but is too hard to fix.” A Scrum But retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the team’s side”. Scrum Buts are structured as follows: (Scrum But) (Reason) (Workaround). Here are some real-life Scrum buts: We use Scrum, but Daily Scrum is too expensive, so we only have it once a week. We use Scrum, but retrospectives are a waste of time, so we skip them. Scrum but can be called restricted Scrum in a broader sense. When the team deviates from a framework, it leaves behind elements you believe are unnecessary.
Poor cross-cultural communication. Interruptions caused by communication occur because cross-cultural communication is also disruptive. According to Sutherland, a sprint is complicated by language barriers, time zones, and adapted work styles, leading to miscommunication and sprint interruptions within Scrum teams. A lack of shared meaning can also cause communication problems.
Sprint goals change. Sprint goals describe what we will accomplish and how it will benefit the business. Developing sprint goals together with the product owner fulfils mutual commitments. The team commits to sprint goals, and product owners agree not to change them. People new to Scrum may need help understanding the sprint goal and how it affects the sprint initially. Changes and clarifications are different. When sprint goals are changed, it creates waste, disrupts workflow, or increases the scope of work—for example, adding or expanding product backlog items. Sprint goal clarifications, however, provide further details to assist the team. In the process of completing the product backlog, the team is perfectly entitled to ask clarification questions. Sprint goal adjustments, however, are a rule, not a law. It is the right decision if change has fewer economic consequences than not doing it.
Scrum frameworks base pragmatic choices on agile principles, so understanding these principles is essential. When the sprint goal is no longer valid, a Scrum team can terminate it abnormally because continuing with the current sprint makes no sense. When the product owner abruptly terminates a sprint, scrum teams meet to conduct sprint retrospectives (other actions may be more appropriate). Scrum teams and product owners plan the next sprint. Invalidating sprints should be reserved for economic events that completely disrupt features’ and flow.
Running out of time. The accuracy of 2-week sprints is less than 100%. When unforeseen problems arise, a simple task can become a big challenge. Sprint teams need more work done in less time. Sprint progress can be evaluated using a burndown chart. Burndown charts help track remaining work. The team may have yet to hit zero hours by sprint’s end. Based on burndown trends, this is evident.
The sprint is structured so teams have no work left at the end. A sprint’s end date must remain the same. Teams have four options in this case if they are unable to meet the two-week deadline: Work overtime to cover the difference. Reduce lower-priority PBIs by negotiating with the product owner. Request a sprint reset. Make sprint goals more straightforward to reach.
Running out of work. Sprints are sometimes completed before the end. There are usually enough housekeeping and polishing tasks even a day or two before a sprint ends. Estimate and complete a small PBI if work runs out sooner than expected.
Management’s Lack of Understanding of the Scrum Process. Plan-based software development projects often need to pay more attention to requirements elicitation best practices. Research has found that half of the projects investigated required clarification. A sufficient understanding of Scrum processes is necessary for Scrum teams to decide what requirements to include in sprints. Estimates and velocity should guide decisions.
