Jira Tickets
Assign additional costs/consequences for generating a ‘bug’ type ticket, such that users/testers will have to resort to writing them down in the comment section of a larger, but only tangentially related feature ticket that had the misfortune of being ‘in progress’ at the time of discovery. Writing a comment instead of creating a proper bug ticket has the additional benefit of not being able to define a template (Steps to Reproduce), ensuring the bug description stays sufficiently vague. Proceed to track the status of this minor bug by adjusting the status of before mentioned larger work item, which by now has already been implemented. This latter point is important to ensure maximal confusion and contextual load required by the developers during daily standups. This serves the dual purpose of extending the standup to 30+ minutes, and ensuring your developers are well and truly tired before the day has even started.
Jira Boards
Create a highly customized board layout that requires at least half an hour of onboarding even for people that are familiar with Jira. Add little energy barriers here and there that only make it into the muscle-memory of daily users. A good example of this is to create label or e pic based swimlanes. Choose a title for this swimlane that’s only somewhat similar to the actual label/epicyou are filtering on, and DO NOT specify a default value. This will ensure that even if casual users create new tickets and somehow manage to fish them out of the backlog, they still end on the bottom of the screen in the second or the third swimlane, effectively hiding them on on any laptop screen. The benefits of this are twofold:
- Casual users will end up frustrated with the ticket creation process, leaving the sole responsibility of synchronising the state of the board with actual work being performed on the shoulders of the PM or scrum-master.
- Tickets will go unnoticed, leading to PMs creating duplicate tickets.