Scrum: obsolete backlog items and external impediments [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 4 years ago.

Improve this question

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?

Answer 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.

Answer 2

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.