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

Question

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 1

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.

Answer 2

There are some subtle differences to understand with Scrum.

In Sprint Planning, the product owner gives the next highest valued requirements to the team that he/she wants delivered based on the teams velocity. The PO explains the requirements and the team question the PO on specifics.

Note: This should not be the first time the team is seeing the requirement as they should have seen it before in grooming sessions.

The team discuss their approach, do their designs and create a heap of tasks to do and agree to the forecast. The team produce a sprint backlog, sprint goal and start working.

No-one can change the core requirement the team is working on; not even the team. Only the PO has the right to terminate work if he/she sees no value in continuing with it. There is a fine line here between bad planning on the PO's side versus clarification of the requirement.

The requirement is not a contract, and the team should have the core just to what has to be done. Details should gathered and work slightly altered to get the requirement done. The team can fully change the tasks they are working on, add more tasks or remove tasks to help communicate and collaborate; only as long it is to deliver the requested requirement. Clarification of details is totally acceptable.

The challenge most teams have is where clarification, changes the meaning of the requirement. When this happens, you should nip the issue in the bud in a retrospective and adapt to the way you write requirements; thus removing ambiguity. It simply means you need to spend more time grooming.

To answer your question. Please if the PO and the team feel it makes sense to alter something ... do it. However, this should be more the exception than the rule. If it is occurring all the time; your grooming is bad. There is nothing wrong with clarifying acceptance criteria and enhancing quality in Sprint.