12

What should we do if a item in scrum takes longer then expected? i am asking this because i have been noticing items that developers is struggling to complete as it is much tougher then initially thought.

In such situation should we

  • remove the item from sprint back to product catalog so that we can meet the sprint timeline?
  • move to easier sprint item and leave problematic sprint till the end of timeline
  • justify at sprint review why the item cant be completed at current sprint to stakeholders?

How can we avoid such situation in future? Is it due to lack of upfront planning or we did not make an effort to break down the sprint item into smaller item?

Improve this question
4
  • 1
    What should we do? We should think about it.
    – rwong
    Commented Jul 9, 2013 at 4:24
  • 4
    We should think about it, and talk about it.
    – Bryan Oakley
    Commented Jul 9, 2013 at 11:05
  • 1
    We should think about it, talk about it, and decide what we should change for future estimations.
    – Michael Durrant
    Commented Nov 30, 2013 at 3:34
  • Define item.. is it a task or product backlog item like user story.
    – Asim Ghaffar
    Commented Dec 6, 2013 at 19:46

5 Answers 5

Reset to default
15

With "item", I suppose you mean "task".

Planning optimism in software is as old as software itself. The good thing about scrum is that you are facing it soon and create visibility of it: this is why the teams velocity is based on past data and not future estimates.

To complete a story, you also have to complete the tasks that turn out much harder than anticipated. No excuse to postpone them. (This is why the Definition Of Done is so important). If that means that the team is failing a story, then too bad, you will have something to talk about on your next retrospective. Velocity will go down (become more realistic) and the team will learn to make better estimates, or leave more safety margin for unforeseen tasks. The product owner will get a more realistic view on his release planning.

Improve this answer
1
  • I wouldn't say "then too bad". It's not bad, it's just data that the team can use in the next planning session.
    – Bryan Oakley
    Commented Jul 9, 2013 at 11:04
12

What should we do if a item in scrum takes longer then expected?

Assuming that by item you mean story, at the end of the sprint you typically put it back in the product backlog (and likely plan it for the next iteration). The team scores zero points for it in the current iteration.

Another alternative, if the story is big enough, is to slice it vertically. For example, the story "product catalog search", can possibly be split in "search by category" and "full text search", but not in "search form" and "search results".

How can we avoid such situation in future?

There is no easy direct answer to this. In scrum you do sprint retrospectives every iteration, where you typically discuss these kinds of things with the team. There are many different possibilities:

  • The team, or some team members, has a bad week
  • Your team pipelines work items horizontally (e.g. backend->frontend->QA)
  • The stories are too big by mistake
  • The team "gold plates" the stories by adding extra work which is not strictly necessary for the completion of the story.
  • The stories are very big in nature, you need longer sprints (unlikely)
  • The team estimates stories imprecisely (incoherently)
  • The project has a lot of tech debt/rotten code base and your velocity is too low
  • You are not measuring and estimating your sprint capacity correctly (or at all).

etc. etc.

Improve this answer
4

You say you won't finish it, but that's not bad, that's just data.

"Meet the sprint timeline" isn't a goal. Your goal is to complete user stories. The timeline is just a tool to help you measure and learn how much work you can do in a sprint.

If you are certain you can't finish the work in the sprint, one solution is to move it to the bottom of the priority list and work on the other stories in the sprint first. Then, with the time remaining you can begin to work on it. Re-estimate the work going into the next sprint and finish it then.

Make sure in your retrospective that you discuss what went wrong so you can improve your estimates in the future.

Improve this answer
2
  • The OP is not asking what to do in terms of development or delivery. What he is asking is how to reflect this situation in the methodology, so answering "it's just data" is not an answer to the question.
    – Sklivvz
    Commented Nov 29, 2013 at 20:09
  • @sklivvz: I suppose, but my point is that you shouldn't do anything special to reflect it in the methodology -- it is already reflected by virtue of the story not being completed. That's all (IMHO) that needs to be done. Scrum isn't about having special rules for special circumstances. Just track the data as it comes, and use the data to help you plan better in the future.
    – Bryan Oakley
    Commented Nov 29, 2013 at 22:43
2

If a task takes longer than expected, this should be brought up in the retrospective and discussed. Was there some piece missed in the early analysis? Was this something that hadn't been done often already by the team? There are lots of possible reasons why something may take longer than initially estimated.

The team should try to get the task done as best as possible and then in the retrospective discuss strategies about this in the future. If the team is fairly new to using Scrum then it may be part of working out the team's initial velocity. Some teams may think they can do 20 points and some teams may do 60 points, the point is how consistently can the same number of points be done each sprint.

This will happen in the future as any time the team has new tasks it hasn't done before there will be some time taken to work out the kinks of making estimates. This is part of the learning process that shouldn't really be that surprising.

Improve this answer
1

What we usually do in our company when a task starts to take longer than expected is dividing it into smaller tasks.

That way we don't put all the blame on the developer for being too slow, but we also acknowledge that the task was designed incorrectly.

Another thing could be to assign the task to another member of your Development Team to avoid your late developer digging himself into a hole. And if the task is really critical some XP could be the solution.

Improve this answer

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.