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?

Hard

This question is off-topic because it's not within the scope for this site, as defined in What topics can I ask about here? Also see: What types of questions should I avoid asking? You may be able to ask on another Stack Exchange site, for example Project Management or Software Engineering. Be sure to read the on-topic page in the help center for any site on which you intend to post a question. – Eno

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.

Trisa

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.

Bachelorism

Answer 3

In this situation, we normally let the Product Owner drop the original user story from the sprint, which frees up time in the sprint. With that free time, the PO can request that the new user story (with updated acceptance criteria) be included in the sprint. There is an assumption of course that the new user story can be completed in the sprint's remaining time.

By splitting the process into 2 separate steps, it ensures that the PO understands that some work must come out of a sprint before more can go in, making the process resistant to future scope creep.

Nombril

Answer 4

Generally, changing AC for a ticket (PBI) is a big no no once a ticket has been estimated, especially within a sprint. That being said, you have to ask what problems it can cause to do so.

Namely changing the AC could cause the estimate to be incorrect - namely too low. So what? Well, that could cause the team to fail to complete the committed tickets from the sprint. That's bad.

A new ticket in this case is probably a bad idea because it doesn't sound like it would fit the "independent" criteria of an INVEST story.

Modifying the current ticket might cause some accounting issues for you when trying to track added stories/points for the sprint, but other than that I don't see any issues. The key here is to re-estimate so everyone understands this is more work.

Try not to get bogged down in what's "scrum-appropriate". Think about what works, what problems different things would cause you and make your decision based on that.

Finally, make sure that this issue comes up in the retrospective so you can discuss why the AC was incorrect or incomplete in this case and see if the team can take actionable steps to prevent that from happening in the future.

PS you may find more help with questions like this over at pm.stackexchange.com

Mercator

Answer 5

I have gone through your question very quickly. Here is the thing. We have had similar situation. We created a delta story and pulled stuff out of the current sprint and moved it to another sprint. Just call it DELTA US and give version 1.1.

Does it help?

Thanks, Kris.

Lujan