The whole development are stuck on one task in a sprint, they would rather work on other tasks then try and solve it. This is the only task remaining in the sprint, all other tasks have finished. The task is not majorly important.

What's the best way to handle this?

  • 3
    Give them an incentive beyond just completing the sprint. Challenge them to find a way. You buy the first round on Friday night for the person(s) who manage to get the last story completed.
    – RubberDuck
    Commented May 25, 2016 at 15:59
  • Is this final task preventing completion of a sprint goal?
    – CBRF23
    Commented May 25, 2016 at 21:32
  • @CBRF23 no it isn't
    – bobo2000
    Commented May 26, 2016 at 8:19
  • 1
    What has the Product Owner said about the situation? Commented May 26, 2016 at 9:14
  • 1
    To forget about that task, and do another one.
    – bobo2000
    Commented May 26, 2016 at 14:42

4 Answers 4


Let the team decide. It's their Sprint goal.

It's a short answer because it's a simple problem. Eventually you have to step away from being a Scrum Bouncer and simply let the team make their own way.

They have a goal, they have a task outstanding. Simply watch and observe and take notes on the dynamic then approach the retrospective with the information.

  • 2
    Agree, they are the owners of the task. No one else can say if the task has to be completed or not. If they know the task they defined is necessary they need to figure it out. If not, they can also decide to remove the task from the sprint backlog.
    – MasterPJ
    Commented May 26, 2016 at 11:14
  • 1
    ++to the Scrum Bouncer
    – sheidaei
    Commented May 26, 2016 at 14:29
  • We ended up replacing the story with an equivalent story and the put that story in the backlog.
    – bobo2000
    Commented May 26, 2016 at 14:43
  • @bobo2000 I'm confused by your last comment. Was this a task or a story?? I agree with Venture2099 - if a story can be completed without needing to finish a task, then the team can decide to remove that task. However, the team should not be removing stories during a sprint. If the team fails to complete all stories due to time constraints, this should be reflected in your velocity and be used for future planning. But they should not be abandoning a story mid-sprint to work on something else.
    – CBRF23
    Commented May 31, 2016 at 9:37

The first step is to understand why the team cannot progress.

What is the challenge? Help them resolve it by removing obstacles, facilitating help/support/knowledge transfer from people or teams.

Encourage the team to complete it, as unfinished items in sprints create a habit of leaving things behind.

Help the team to stay focused and finish the task.

On the other hand, if however, the task is not resolvable, make sure you discuss it in the retrospective.

Understand why it turned out to be so. For example, is this indicative of a lack of skills which you need to address? Is it reflective of the lack of planning you have done? Is it the story itself? Is it inappropriate to include such unimportant tasks in sprints if they take up time but add no value?

Agree to the action items/changes you would need to make so that this situation doesn't repeat.


What is the value-add of the task? Developers can smell unnecessary work, and pressing them to do something that few people besides yourself care about can lead to resentment or openly challenging you, especially if the task was selected by you instead of the product owner. If this is a nice-to-have that the PO asked for, and there are other more valuable items in the backlog, you may need to talk with the PO about how/why to order the backlog so the team always works on the most important items first; although even so, the team should be negotiating the scope with the PO, not unilaterally deciding what is and isn't worth doing. If halfway through the sprint they decide not to do something, there should be a valid technical/organizational/capacity reason for dropping the task, not just because they don't feel like it.

If there is genuine value in the task, then you need to make sure there are appropriate consequences if they neglect it. Your first option should be to teach them the importance of keeping their sprint commitment. If that doesn't work, have the PO explain to them why this task is valuable and necessary. If all else fails, escalate to their manager.

  • That should not really be an issue. I agree with your sentiment but if the team accepted the story into Sprint planning and onto the Sprint backlog then mid-Sprint is not the place to start refusing work. The Product Owner prioritised the Backlog based on value. It is not the the Development Team's role to decide what is valuable. Not unless they have some new insight which should be shared with the Product Owner. If stakeholders are invited to the Sprint Review then the team will look amateurish if they turn round and say "We just didn't think it was valuable so we binned it." Commented May 26, 2016 at 8:35
  • My first paragraph assumed that the task had been selected by the scrum master or dev team instead of the product owner, since not all PO's are engaged enough to keep the backlog properly ordered. I'll edit my answer to clarify that.
    – Pedro
    Commented May 26, 2016 at 11:26
  • A carrot is way better motivation than a stick.
    – RubberDuck
    Commented May 26, 2016 at 16:53
  • @RubberDuck I agree, and in many cases a stick should be the last resort. But some people just need a stick, and you need to have it available if needed. Otherwise you can end up with more stuck than two developers.
    – Pedro
    Commented May 26, 2016 at 16:56
  • The stick should always be the last resort. Also, there is no such thing as a Sprint Commitment in Scrum. There's a forecast. It's also probably better to explain the value in the story before lecturing the professionals about commitments and deadlines.
    – RubberDuck
    Commented May 26, 2016 at 16:59

One agile class I took suggested that when a team was stuck on a task, at that point, the Team Lead would look outside the team for assitance. I think this makes sense in an environment where you have multiple teams. I think a decision would have to be made, assuming the task needs to get done, such as either spending more time ramping up on the technical area, or looking for an expert outside the team, potentially requiring a service charge, for example for a team coming up to speed on kubernetes and running into a production issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.