What to do with a commited PBI
There is a bug that we commited to for the sprint. Upon working the bug, it was discovered that the issue was due to system misconfiguration on the customer side and that no software changes were needed.
We have logged that in working with the person who reported it, found that the system was misconfigured and that no further action was needed.
We are also coming up with a plan to better verify bugs before they are accepted by the PO into the product backlog.
We will tell the PO during the review that the PBI is done becuase the bug doesnt exist.
Is this how we should do things? Should we approach the PO ahead of time and have the PBI removed from the sprint immediately instead?
Hi Randy
Tell the PO now. The defect you accepted into the sprint can *potentially* be traded out and other more valuable work brought in. Any work brought in should be roughly equivalent in size to the defect minus whatever effort you put into chasing it.
I agree
Thanks guys!
Another opinion. to Ian's point that the work *potentially* be traded out and other more valuable work brought in... any and all other committed PBIs should be addressed and completed before accepting new work. One or more committed PBI might take more time than expected. If fact, we are very much opposing to take any new PBI at all. Any time available after all PBIs are done can be wisely used by the team such as learning, knowledge sharing etc.
I agree Ravi to an extent.
Taking PBI (not changing the sprint goal) would be based on team's conformance and provided there is such PBI that could be taken up & finished within the sprint. This definitely should be once the forecasted(not committed) PBIs are all done for the sprint. Otherwise, team may spend time on learning, training, KSS etc.