In scrum, is changing acceptance criteria during a sprint OK?

scott degen picture scott degen · Feb 13, 2013 · Viewed 10.4k times · Source

My organization is currently implementing Scrum. While working on a product backlog item to change the way some business logic is processed, we realized that some of the business logic is flawed. The PBI and its acceptance criteria are currently oriented towards modifying the implementation of the existing business logic. The PO feels this change to the business logic itself is a high priority and should be worked into the sprint somehow, and the dev team agrees, especially since it would make a lot of sense to do both things together, from a development standpoint.

We are unsure, however, if it would make more sense to modify the acceptance criteria or create a new PBI and pull it into the sprint right away. I personally lean towards a new PBI because I feel like this is a separate story and set of acceptance criteria from the original PBI, and I'm skeptical about changing acceptance criteria mid-sprint in general. The PO pointed out that both this new requirement and the original PBI will be implemented at the same time, and the original PBI is pointless without the new requirements to be addressed. So the PO feels it would be more appropriate to adjust the acceptance criteria of the original PBI instead of creating two separate ones that reflect the same implementation in the end.

Is one of these approaches more scrum-appropriate than the other?

Answer

David M picture David M · Feb 14, 2013

You should modify stories only with the concurrence of the team, because they committed to delivering one set of criteria. If you change the criteria without the team's unanimous consent, then why are you bothering to have gotten it in the first place?

It's a big deal to fiddle with the sprint backlog, because then you're devaluing the team's commitment to deliver a particular set of stories during the sprint.

If the team isn't willing to accept the changes, the PO can withdraw the original story and put a new story at the top of the backlog. It might be included in the current sprint, or it might not.

Resist with every fiber of your being the notion that the PO can fiddle with the sprint backlog during the sprint. My PO tried to drop a really tiny story (based on some very bogus reasoning) near the end of a recent sprint.

From http://www.scrum.org/scrum-guides/ :

Only the Development Team can change its Sprint Backlog during a Sprint.

I think that's good advice, and you should disregard it with great trepidation.