Menu
Specifically, should you only accept new work you know the team can finish in the given iteration? Is it ok to start the next highest priority backlog item even if you know the team doesn't have time to finish it? Thanks!
631
So here goes… If the Team finishes early, it seems to me there are two choices: take a holiday, or do something new. I have seen Teams take a half-day off if that's all the time they have left, and I applaud this. In most cases, however, the Team should just bring something new into the Sprint and do it.
If a team is ahead of schedule, it's still ultimately up to them as to how to manage their work. I suggest asking them what their stretch goal should be relative to the next highest-value yielding work in the product backlog, all while providing transparency to the PO.
4) What happens if the Developers cannot complete its work by the end of the Sprint? The Developers inform the Product Owner. The Scrum Team should then inspect & adapt to prevent this in future if it is a problem.
If your team has finished all stories before the expiration of the time box defined by the Sprint, the team is encouraged to work with the Product Owner to select additional stories off the top of the Product Backlog that may fit within the time remaining.
We use the time to fix bugs, and to pay back some technical debt.
If you can do this without talking to your product owner depends on your understanding of scrum or your work arrangement with the product owner.
In my personal opinion you make a promise for the sprint. Your part of the deal is to hold the promise. The Product Owner on the other hand is supposed to stay out of technical stuff, since that's what the developers are good at. Technical Debt is technical stuff. Bugs might be. But in the end you have to come to a common understanding with the PO what you can decide on your own and what you have to consult the PO with. In an ideal world the developers know so much about the product that they can make the decision on their own.
Starting on the next item is of course another option. If you can't finish it, Lex Scrum says don't touch it. And I like this law to some extend, because it actually creates slack that can be put to good use by developers ... like fixing bugs and paying back technical debt. If implementing another story is the best use of your time: find one that you can finish. If you can't find/create one, this is actually an impediment that you just found. Assuming we are talking at least about something like 4hours for 2-3 developers, we really should be able to find something useful to implement with these resources, shouldn't we?
78
should you only accept new work you know the team can finish in the given iteration? Is it ok to start the next highest priority backlog item even if you know the team doesn't have time to finish it?
Remember "Individuals and interactions over processes and tools" Do what your common sense tells you. Do not get too caught up in tools and processes.
As per the Scrum guide, the amount of work the Team commits to is completely up to the Team.
There is no harm in starting a next highest priority item when all the items above it are done. What would be preferable though is break the item down into a smaller or thinner slice which can actually be done.
If the Team finishes all it's Backlog Items well ahead of time, the team should definitely take up a few more.
37
I would take the next highest item in the backlog and work with the product owner on creating a story that can can be completed in this iteration...so break the story into a smaller size to fit.
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
