Scrum Challenges

3 Challenges facing New Scrum Teams

Scrum is a great framework. Its emphasis on collaboration and creating self-organizing teams is path-breaking. Unfortunately, creating a self-organizing team that delivers in a sustainable manner is not child’s play – it may take anywhere from 6 months to years depending several factors. And, during that long period – from adopting Scrum to becoming a mature Agile team – a team may face several challenges. Based on my personal experience and feedback from hundreds of my training participants, below are the three most common challenges a Scrum team may face:

  1. Inefficient resource utilization
  2. Not able to finish all committed stories
  3. Managing scope changes during Sprint

1.     Inefficient Resource Utilization


Testers are lightly loaded at the beginning of Sprint and heavily loaded towards the end. Developers may be lightly loaded or heavily loaded towards the end depending on the size of their story and the number of defects found for their work.

Possible Side Effects:

  1. Lower or fluctuating velocity
  2. Poor product quality, high technical debt
  3. Poor customer satisfaction
  4. Poor team motivation and self-image

Primary Causes:

  1. Waterfall within a Sprint – Developers starts coding for all stories while the testers write unit tests and wait for completion of dev work – leading to their lower utilization. As developers finish coding around day 6 to 8, it leaves little time for testing and usually creates a panic situation leading to high stress for testers.
    Following are some of the primary reasons why work flows like waterfall within a Sprint:

    • High degree of specialization or lack of cross-functional skills
    • Organization culture of tracking (and rewarding) individual performance – leading to each developer picking their own story
    • Poor collaboration among team members – for reasons other than the previous point
    • Lack of mature Agile expertise at team’s disposal (read ineffective Scrum Master/ Agile Coach)
  2.  Nature of the Sprint – While a more mature team will exhibit better utilization of its resources, there are good chances testers will be somewhat relaxed in the beginning and a little stressed towards the end. That is the nature of a strict timebox.

Possible Solutions:

  1. Limit WIP: Limit the number of stories in progress at a given time. If a team picks six stories, they should try to start not more than 3 (or 4). Only when one of them is done (ideally before half-sprint mark), the fourth one can be picked. And, so on.
  2. Encourage Dev-Tester Collaboration: A tester could sit with the developer helping them write better unit tests, or share their test cases with developers – both will help fix bugs before they are identified.
  3. Encourage Developers for Testing: This could be a tough conversation as developers may feel they are being asked to do less challenging work (skill downgrade). You may want to make it easy for them – like asking them to run through all test cases before handing over to QA. Retrospective may be a good place to bring up the issue for team discussion.

2.     Not able to finish all Committed Stories


The team commits for 6 stories but can finish only 3 to 5. The unfinished stories need to be taken to next sprint. Or worse, maybe de-prioritized by the PO, making the team feel unhappy.

Possible Side Effects:

  1. Fluctuating team velocity
  2. Poor team motivation and self-image
  3. Poor team performance rating by business and/or management

Common Causes:

  1. Waterfall within a Sprint – Developers starts coding for all stories while the testers write unit tests and wait for story completion. Developers finish coding around day 6 to 8, leaving insufficient time for testing and fixing defects.
  2. The inherent variability of effort in knowledge work – Knowledge work is different from defined work (manufacturing). One 5-point story takes 35 hours while another could take 70 hours. This makes it difficult to say exactly how many stories (or points) a team will be able to finish within a Sprint (strict timebox). While a team may want to under-commit and improve their success rate, business/management will usually be too eager to push more towards over-commitment.
  3. The team struggles to estimate story size – could be due to the new business domain or new technology.
  4. Estimates are forced onto the team, by a “powerful loudmouth” – team lead/manager, PO or some other influencer. While it may sound quite illogical, I am sure most of us have seen this happen.

Possible Solutions:

  1. Limit WIP: Limit the number of stories in progress at a given time. If a team picks six stories, they should try to start not more than 3 (or 4). Only when one of them is done (ideally before half-sprint mark), the fourth one can be picked. And, so on.
  2. Flexi-Commitment: Pull in 120% of average velocity, with a hard commitment to finish more than 80%. So, if a team velocity is 25 points, they will pull 30 points worth of stories from backlog, and aim to finish at least 20 points.NOTE: This option must be tried only with the previous option, otherwise there is a risk of having too many stories in progress – leading to more chaos.
  3. 3-point Estimation Scale: If poor estimation is the key cause, the team may try a shorter estimation range. I have seen 3-point scale work really well for new Agile teams. You could use Small, Medium, Large and equate them to story points – say 1, 3, 5 or 1, 2, 4.
  4. Transition to Continuous Flow: Using Scrumban(without sprints) or Kanban Method.

3.     Managing Scope Changes during Sprint


Team commits for 6 stories based on their historical velocity. While the Sprint is in progress, PO brings important requirement changes to existing stories, or completely new work that is deemed urgent.

Possible Side Effects:

  1. Team velocity may down for the Sprint
  2. Multiple incomplete stories
  3. Wastage – rework or lost effort
  4. Stressful work environment – in case ad hoc changes become the norm
  5. Poor team motivation

Common Cases:

  1. Ineffective Product Ownership: The examples could be multiple – ineffective coordination with customer, lack of timely grooming and prioritization, high subjectivity in business value identification, etc.
  2. Demanding Customer/Business Reps: Their belief could be in Agile they can change anything any time.
  3. Dynamic Business Model: The business model could be so dynamic that high value requirements need to be addressed as soon as they are identified. I witnessed that at one my customers – business would often come with feature requests that needed to be done within a few days.

Possible Solutions:

  1. Make it a Negotiation: Each change should be approved after a negotiation between the PO and the team, to be facilitated by the Scrum Master. Please see this article for more guidance: Should we allow Changes within Sprint?
  2.  Transition to Continuous Flow: If your business model is like Case# 3, you may want to explore Kanban Method. On how Kanban Method may provide more options for dealing with unplanned scope changes, please see this article : Scrum vs Kanban - Managing Change Effectively.


Thanks for taking time to read this article. Request you to share your thoughts on this article and your personal experience on what common Scrum challenges you have seen and how you were able to resolve them. Cheers!

[This article was first posted on LinkedIn. Please find the original post here.]

Leave a Reply

Your email address will not be published.