Workflows of rejecting tickets due to incomplete/wrong implementation

Question

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?'

Answer 1

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.

Answer 2

Analysis

Your current process contains a large set of agile anti-patterns. Some of these process dysfunctions include:

1. "Testing" divorced from a Definition of Done (DoD).
2. Lack of test-first development.
3. Sequential (rather than collaborative) activities.
4. Treating changes (other than DoD gaps) as rework rather than new work.

While JIRA's ticketing model is arguably unhelpful in addressing your problems, the process problems have very little to do with JIRA itself.

Recommendations

The entire organization needs to evaluate the cost of doing business the current way. If everyone is happy with the project's ongoing development costs, number of hand-offs, inter-team friction points, product quality levels, and overall development efficiency then there's nothing else to do. Declare victory, pass around some well-deserved bonuses, and keep on keeping on!

In the more likely event that everyone agrees the process is sub-optimal, stop doing the same thing and expecting different results. In particular:

1. Ensure every single work item has a well-defined and fully-testable Definition of Done.
   • A global Definition of Done that applies to all project work should be defined as part of your core development and product management processes.
   • Clear, objective measures of "done" should be defined upfront as part of the work-item definition.
2. Don't begin work that doesn't have a clear, objective measure of success.
3. If a Definition of Done or testable success criteria are lacking, the work for the iteration should be to develop those measures. You can't expect a building without a proper foundation to stand up very well!
4. Collaborate with testers and stakeholders during story definition to ensure everyone agrees on what should be built and how it will be evaluated.
5. Leave how it will be built to the development team, but ensure that they're building it with the Definition of Done and testable criteria baked in.
6. Collaborate with testers and stakeholders as often as possible throughout the iteration to avoid post facto suitability issues.
7. Treat all work that meets the Definition of Done and any defined test criteria as "done," whether or not it's ultimately fit for purpose. If not, treat that as grist for the mill for your inspect-and-adapt process.
8. Treat all work (other than incomplete work that hasn't yet met the Definition of Done) as new work to be prioritized, planned, and implemented in a future iteration. Any other approach will simply generate perpetual scope creep.

This is not just a development team or product ownership challenge. To solve this systemic process issue will require the entire organization (including senior management, stakeholders, and customers) to participate fully in the process.

Answer 3

If I understood your question correctly, it seems that tasks are not very well defined which is root cause of this issue. While user stories are good to describe a task, one should try to include different mediums to translate and define business need in accurate form for related team members. Project team members has different view points based on their Role in the project, hence including different supporting documents for a feature becomes vital for easy preview and Sign-Off. Once a well groomed Backlog if ready it becomes easier to define the workflow in tangible easy steps.

For e.g. UI, Wireframes, Workflow diagrams, Sequence diagrams, Screenflow depicting different screens and complete dataflow, API signatures, brief objective, Ambiguity check with other business case, test data (username/password/json/xml structure of data etc. etc.), supported environments, etc.

Task/Feature Definition, Backlog Grooming: You must review all relevant data points applicable to your product and ensure that these inputs are well reviewed and discussed to be finalized for any user story to be termed as "Ready for Development". Call the relevant filtered inputs for development as "Check List for User story" creation. Using this check list define clear and non-ambiguous requirement for development, ensure every user story has these inputs as mandatory parameters. Keep your backlog well groomed and Product repository easy accessible and updated for every team member's access and review.

Task Handover from Development Team to QA: Work with Developers to define the Inputs which they are supposed to provide when task is moved to "Ready to Test" Status. Development team must run unit test cases and review implementation low level design validation. A checklist must be submitted as proof for handover to quality team. Release Notes to QA, Deployment Guide, Unit testcase execution report, test data username/password feature-data used (for example URL, username/password, book name if project is about online bookshelf), Impact area etc..

Task Validation by QA: QA team members must be able to create testcases based on User stories as defined by you. These test-cases will form a part acceptance criteria as well. So review the testcases along with development team, get most important and frequent testcases included in unit test cases for development team's perusal.

QA team will provide Test execution report based and log all test execution in details. like URL/App version, Username, Password, Feature Name which is reviewed, API captures, Session Captures, screenshots, steps to replicate, actual vs expected output, environment details in which this issue is replicating (all/specific environment) etc.

QA Handover to Deployment: Verified tasks can be taken forward for production deployment. This can be supported using deployment guidelines, where agreed way for deployment of verified tasks, with version control and rollout plans are well defined with Final User acceptance validation for Defined Business Requirements.

Success Criteria This must be included at Project level for definition of Project/Milestone/Release success.

You can include/exclude the steps based on kind of work and requirement, but It is very important to define the framework or Workflow which is reviewed and agreed by every team member involved in the project.