What to do with a branch and card when a task meets the acceptance criteria BUT user testing reveals it's not acceptable?

Question

Firstly, I think this is a common ground between software development and PM but believe I have posted this in the right community.

---

I have been recently coming into this situation more and more and wanted to know of a solution or recommendation from people have who have experienced this situation.

We use Jira to define our tasks and have acceptance criteria (AC) that are defined by our Product Manager (PM). When a developer works on a task, they have to achieve the result of the AC and that is reviewed by the PM.

Recently, we have had a few situations where the PM has decided that whilst the AC has been met, the code should not reach production as it does not deliver a suitable enough value to our user. This means that we have a situation of limbo where both the card and the code sit whilst the PM decides how best to resolve the problem.

I wanted to gather some thoughts on what the best practice for this is. I personally do not believe in shipping a product that is of negative value to the user, but also believe that holding features in limbo and producing a potential for merge hell is not great for our development team when the AC was clearly met.

Answer 1

I also believe that the most concerning part is:

the PM has decided that whilst the AC has been met, the code should not reach production as it does not deliver a suitable enough value to our user.

I see three possibilities here.

1. The PM does not believe that the AC need to include providing value.
2. The PM is not putting in enough effort to the AC to include value.
3. The PM tried in good faith to include value in the AC, but they still don't. Either because life happened and the AC changed, or because there was miscommunication between the PM and the devs, so the devs never built what the PM was expecting.

The first two are easy to address - the PM needs to start making actual acceptance criteria; such that if the criteria are met, then the task is accepted.

But no one is perfect, so I'll now address that third possibility.

First, before anyone ever starts working on a task, make sure that the task is reviewed, by both the PM and at least one dev, to ensure that the AC make sense to everyone and include value. Everyone at the table, when looking at the task definition, should understand why the task even exists.

Next, if and when it becomes apparent that the AC do not include sufficient value for the customer, immediately stop lower-priority work and fix it. Take a look at the theory behind Kanban Work-In-Progress limits. Always try to focus on the highest-priority tasks, even if they're blocked, rather than immediately just jumping to pull even more work in progress. No merge hell if the devs aren't developing anything else until the issue is resolved, after all.

Answer 2

I doubt that there is a technical solution to this problem. The underlying issue is in the product management space. The fact that the product manager is specifying what to build, having the team go out and build it, and then deciding that the wrong thing was built is extremely wasteful and costly. Rather than trying to figure out what to do with these features and the code behind them, figure out how to get the right information to the developers sooner and keep the product manager involved in the daily work of the developers to make sure that they are indeed building the right thing.

Unfortunately, there's not enough information to understand why the product manager isn't able to convey the right information about what to build. Without that, I'm not sure it's possible to get to a solution. So figuring that out is the first step. Of course, this kind of thing is bound to happen sometimes - people make mistakes, miscommunicate, and misunderstand each other. However, it should not be a regular occurrence, and getting to the root cause and solving it is crucial.

Answer 3

I'm not a big fan of Feature Toggles (because they can become a maintenance and configuration nightmare if not properly managed), but this could be a solution for deploying the code, without making it available to users. When the Product Manager (PM) eventually decides a feature can be shown to users, you just toggle the feature and later remove the feature toggle from the code.

However, what worries me is this part:

[...] the PM has decided that whilst the AC has been met, the code should not reach production as it does not deliver a suitable enough value to our user.

If it doesn't deliver enough value to the user then why build it now? Why not build it when it delivers enough value to the user? Or why build it at all if this is not a "value depends on time" situation?

You also mention:

I have been recently coming into this situation more and more [...]

The problem is how the PM is acting in regards to the features you build, and not what to do with the branches and the cards while the PM takes a decision about your finished work. Your PM most likely needs help in refining the backlog and prioritize features so that they do deliver value to the user, and make better decisions about what to provide users now instead of putting things on hold. Talk to the PM to figure out why this behavior is happening and how you could eliminate it or reduce it going forward.

Answer 4

Your PM seems to be acting a bit like a user who doesn't really know what he wants until he sees it in action. Then you can do all the sign-offs you want, but you may still end up with the response "this is not really what I had in mind".

Such responses are probably a fact of life and you will have to find a way in which the PM can say "This story is completed according to the AC, so I accept it, but I don't want it in production yet." A common way to facilitate that is to use a Feature Toggle.

Answer 5

May I gently suggest that the question you are asking is what to do about a symptom, and that there is a more important question to be asked about the cause?

To answer the question you are asking, I suggest creating a new workflow state, REJECTED, which is a resolved state. Put these tickets in that state.

Exactly what to do about the associated branch will likely vary for each ticket.

I believe the more important questions to ask, and answer, for this and every subsequent case are: How did this happen? What can we do in future to keep it from happening again?

Document the discussion and decisions in the rejected tickets.

Use metrics based on the REJECTED state to document, not only how often it is happening, but how much wasted effort it is causing the company (assuming that you are using time tracking in Jira). Inspect those metrics regularly.

In terms of how to fix the general problem, I would ask,

• why isn't user acceptance part of the acceptance criteria?
• is the design team showing design mockups to real users and iterating?
• is the development team showing early implementations to real users and iterating?

Good luck!