7

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 May 25 '16 at 15:59
  • Is this final task preventing completion of a sprint goal? – CBRF23 May 25 '16 at 21:32
  • @CBRF23 no it isn't – bobo2000 May 26 '16 at 8:19
  • 1
    What has the Product Owner said about the situation? – Barnaby Golden May 26 '16 at 9:14
  • 1
    To forget about that task, and do another one. – bobo2000 May 26 '16 at 14:42
12

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.

  • 1
    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 May 26 '16 at 11:14
  • ++to the Scrum Bouncer – sheidaei May 26 '16 at 14:29
  • We ended up replacing the story with an equivalent story and the put that story in the backlog. – bobo2000 May 26 '16 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 May 31 '16 at 9:37
8

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

(1) understand why it turned out to be so? For eg, Is this indicate the 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 to sprints which takes up time but add no value?

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

0

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." – Venture2099 May 26 '16 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 May 26 '16 at 11:26
  • @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 May 26 '16 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 May 26 '16 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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