Workflows of rejecting tickets due to incomplete/wrong implementation



  • I work as a product manager in a start-up. We try to be lean but we have Jira as a tracker (I said we 'try'). I worked in around 10 different teams so far and the development workflow was usually similar, except the part where the person who accepts the user story rejects (not-accepts) it.

    What are the best practices here? We currently do the following:

    • User story lands to the 'user acceptance test' column.
    • product manager reviews the story and goes through the acceptance criteria 1 by 1.
    • PM writes a comment with each criterion's status (X or ✓) and moves the ticket back to To Do
    • Engineering lead checks the comment and aligns with the engineering team to re-create new sub-tasks.

    I have a feeling that this is not so optimal and would like to hear your opinion. How is your 'rejection workflow?'



  • How is your 'rejection workflow?'

    If you need a workflow to handle rejected user stories, then you have a problem.

    Normally, a user story being rejected should be an exception; someone misunderstood something, someone made the wrong assumption, someone failed to communicate... it happens. Nobody's perfect. But when it happens it's something that it's subject for improvement. It's about 'inspect and adapt' so that it no longer occurs again (or occurs even less).

    User stories should have properly defined acceptance criteria and there should be continuous collaboration between developers and product manager so that you build the right thing. Having and 'user acceptance test' column is enough to signal that an user story can now be reviewed, but if everyone did their part correctly then the user story will almost always be accepted, and very rarely rejected.

    Find out the reasons user stories get rejected, don't try to figure out how to best handle rejections. Most likely, you either don't have a proper 'definition of ready' for the user stories before developers go to work on them, or instead of close collaboration, developers are being assigned work then left on their own until it's time to see what they did.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2