0

How can I deal with sprint backlog items that somehow becomes obsolete or unnecessary mid-sprint? Do I mark them as solved?

What about tasks that are dependent on external factors outside the control of the team?

liewl
  • 4,021
  • 13
  • 46
  • 65
  • 4
    I'm voting to close this question as off-topic because [project management is now off-topic on Stack Overflow](//meta.stackoverflow.com/questions/343829/is-stack-overflow-an-appropriate-website-to-ask-about-project-management-issues/343841#343841). Ask these questions on [SoftwareEngineering.SE](//softwareengineering.stackexchange.com/) and [ProjectManagement.SE](//pm.stackexchange.com/) instead. (Unfortunately, this question is too old to be migrated.) – robinCTS Oct 29 '17 at 17:35

2 Answers2

1

I assume that by sprint backlog items, you mean what is also called tasks, or the breakdown of the product backlog items, as done by the team during the planning session. Just throw the card into the nearest recycling bin, or mark it as removed from a computerized system. You may mark them as solved if that makes sense to you (if by solved you mean no remaining work to be done).

If this happens often, then your team may wish to bring this up in a retrospective. It is an indication of the team not having a clear idea of what needs to be done - either due to insufficient planning, an impaired idea of what the product backlog item is, or possibly changing requirements. You may wish to bring it up with the PO if it is the latter.

With regard to tasks dependent on external factors - you should plan your work accordingly. Separate the high risk components from the low risk ones. have your existing (and low risk) modules interact with the high risk components through interfaces, and design the APIs to have as little of a risky surface as possible.

When building the low risk module, you should stub (mock) the high-risk modules, and you will be well served using dependency injection so that you can then easily swap the stubs for the real thing when the external factors become available. If the external modules do not fit your interface, write an adapter to transform your calls into the external module's APIs.

Even if the external factors are available before you build your software, you should consider doing the above, though developing a stub is not as crucial as it would be if it wasn't ready. Doing this will safeguard your system from future breaking changes to the external components.

Either way, your plans should account for this, and you should communicate the problem to the PO. He will not be able to release any PBI that is missing a crucial part.

Assaf Stone
  • 6,309
  • 1
  • 34
  • 43
  • What about the burndown chart, do I mark the obsolete tasks hours as used up (solved)? – liewl Aug 05 '13 at 11:38
  • As a rule, I would strive to represent reality as much as possible. If you're tracking hours spent, mark those off. Regardless of the outcome (done or removed), you spent this time. You may find it interesting to investigate how much time you spend on obsolete tasks. If you're tracking remaining hours, then you should put '0' because you don't have to spend any more time on it. In the end, how you represent it is up to your team. As long as you can read the reality out of it. Remember - **Individuals and interactions over processes and tools**. – Assaf Stone Aug 11 '13 at 13:06
1

The Scrum Guide covers this eventuality:

During the Sprint:

  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

So, if you end up removing Sprint Backlog Items, your first action would be to return them to the Product Backlog. You don't mark them as "Done" because they're not, and to do so would reflect incorrectly on the Velocity.

Having removed Sprint Backlog Items, the Development Team may feel that they have capacity to bring other Product Backlog Items in to the Sprint. That's their call.

Later, perhaps during Product Backlog Refinement, you may decide that the removed Product Backlog Items are no longer useful. You could then remove them from the Product Backlog, updating any Product Roadmaps or Release Burndowns that had included those items.

Derek Davidson PST CST
  • 1,799
  • 12
  • 17
  • In that case, what should be done to the burndown chart and the total effort for the current sprint? If I don't bring any new items from the product backlog to fill up the abandoned tasks's estimated effort, should I just reduce the total estimated effort for this sprint? – liewl Aug 06 '13 at 14:54
  • @DavidMcDavidson Burndown charts are beautifully simple and show effort remaining on a given day of the sprint. That's it. So, for example, let's say you have 90 hours of effort remaining. You remove items from the Sprint Backlog that total 30 hours. The effort remaining on the Burndown chart should now show as 60 hours. – Derek Davidson PST CST Aug 06 '13 at 18:33
  • When that happens what do you do with the chart? Do you draw it again but with a total of 60 hours instead of 90? Because just subtracting those 30 hours from the total would make it look like the team spent those 30 hours completing tasks. – liewl Aug 06 '13 at 18:50
  • The Sprint Burndown chart exists *only* to show whether the team is likely to deliver on time. In this context, whether you have worked off the 30 hours, or discarded them, is irrelevant. I just plot the hours remaining for each day, as it happens. After reflecting the discarded 30 hours worth of work, re-draw the trend line. If it looks like you're going to finish early, the Development Team should have a chat with Product Owner to see if there's additional work they can usefully pull in to the Sprint. – Derek Davidson PST CST Aug 06 '13 at 18:56