What Happens When A Story is Not Accepted

Acceptance Criteria for Data-Focused User Stories: Part 2

In the first part of this blog series, I defined what acceptance criteria are and why data teams need them. Now, I am going to address a possible outcome related to acceptance criteria when it comes to a user story:

What happens when the product owner does not accept a story?

The answer is not a simple one-size-fits all, as there is no one way to handle a story that is not accepted. The product owner actually has four different options depending on the situation:

Choice #1

Make the story a top priority for the next sprint. In this scenario, the product owner decides that this work is important enough to take precedence over other work. They bump the next items in the sprint to continue work on the current story until it’s ready to be accepted.

Choice #2

Slice the story thinner and prioritize the slices. This happens when the product owner decides that certain pieces need to take priority, while others do not. This also happens when some pieces are right and others aren’t. So they slice it to distinguish them apart and rework the pieces that need it.

Choice #3

Delay it until a later time. Sometimes, stories take longer than expected. It is up to the product owner to determine whether or not effort is being put in the right place. Other stories may bring value faster, and so that story may be put back into the backlog to make time for others.

Choice #4

Abandon it. In some cases, the story may be abandoned. This is a healthy response of a mature product owner, and it typically happens when the data does not provide the information the product owner was hoping to get. They see that what the team can realistically create based on what’s in the system is not what they or the stakeholders had envisioned.

There are several ways to handle a story that is not accepted by the product owner, and the correct response must be decided on a case-by-case basis. It is important that the data team stays focused on creating value, and that requires regular reviews and adaptations. The sooner the team knows there is an issue, the better. This is why it is imperative to do reviews iteratively and as soon as possible. This way, there are no surprises or time-consuming fixes at the end.