2

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.

2
  • What do you mean by "deliver a suitable enough value"? Is the problem that the changes are incorrect? Are the changes correct but not usable? Is the cost of delivery greater than the value in the set of changes? Depending on the exact problem(s), there are going to be different possible solutions.
    – Thomas Owens
    May 6 at 12:16
  • Thanks for your comment @ThomasOwens. I am the tech lead on the project, rather than the PM to get this confirmed. We are delivering what is asked for in the AC, but our PM is deciding that what he requested does not actually work for the user (eg. He thought they wanted a bike but after testing it post development he realised they wanted something else... as a broad and slightly outrageous (but fitting) example). Our problem is how do we maintain that limbo state.
    – alexc95
    May 6 at 12:50
3

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.

3
  • Hey, thanks for your comment. Lots of perspectives are really helping. I think you, and many others, are right in saying that there is an inherent issue here that is greater than the technical qualms of having code existing on an open branch for a few sprints. My PM is very insistent on it delivering value and I believe this is why this situation happens. If something is delivered that is to spec, meets the AC and hits all design requirements, he could still stop it on the basis that he believes that there may be an issue with the UX etc.
    – alexc95
    May 6 at 13:34
  • 1
    @alexc95 The acceptance criteria are supposed to be acceptance criteria. Treating them as anything else is where your problem lies.
    – Sarov
    May 6 at 13:35
  • As an example: Recently we worked on a button that had multiple ways of interacting with it. The UX team signed it off, PM created an AC for it and we agreed on the AC. The work was done and as we went to sign off the actual work (Post development) the PM decided that the feature could confuse users and decided to hold it off whilst he investigated. This is the general situation that has occurred around 2-3 times in the past 2 sprints but seems to be slipping in.
    – alexc95
    May 6 at 13:35
1

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.

1
  • Hey, thanks for your comment. Really appreciate it. I totally agree with the wastefulness and also the fact that our engineers can feel quite deflated by working on something to have it pushed back. I explained above (Which I think I will add to the initial post now) that we have had UX research, then design, then an AC created by the PM and then the dev team delivering exactly what was asked of the AC. The problem comes from the PM then deciding that despite us building what was asked, he "product" needs to be changed.
    – alexc95
    May 6 at 13:31
1

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.

3
  • Hey, thanks for your comment. Greatly appreciated. The problem we are having is that we are meeting what the UX team has designed, what the PM has approved but then reaching a road block when the PM decides that after a length process of defining what something should be, pre-release PM has decided that it is not exactly what we want (A good example is probably what I said above him thinking that we should deliver a bike, us delivering a bike, only for him to realise its not what PM wanted (Or customer) despite that being exactly what PM asked for).
    – alexc95
    May 6 at 12:52
  • Our UX team delivered this design, our PM approved it and set out the acceptance criteria and the development team built it. We tried feature flagging, but like you suggested it can create stress on development time and still technically adds on to the process (Do you plan to add it to a feature flag before or after you make the mistake?). This sprint it has happened on multiple features, with one feature being held back for 2 sprints. This resulted in large merge conflicts which obviously wasn't great for the development team.
    – alexc95
    May 6 at 12:56
  • @alexc95: based on the comments you posted, the problem is definitely not a technical one of how to handle branches or tasks, but an issue of how the PM does their job. Planning out a sprint with some work only for the PM to change their mind at the end isn't how a sprint should happen. There might be a fear of commitment coming from the PM, or maybe a lack of knowledge or understanding of the domain, or communication problems with stakeholders, or any number of issues. Talk to the PM to figure out why this is happening and how it can be eliminated or reduced going forward.
    – Bogdan
    May 6 at 19:11
0

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.

0

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.