User stories: to template, or not to template?
Confession - I hate JIRA templates...
It’s finally September - the days are shortening, the leaves are darkening, and product managers everywhere are bracing themselves for a flurry of tickets as their teams look to meet their 2022 goals in the last few productive months of the year. There will be lots of new requests to wade through, but how can we best use our Agile software to get the right information across?
Some PMs like to have their stakeholders fill out templated JIRA forms, asking questions such as ‘What benefit do you hope to see from this feature?’ ‘What metrics or KPIs will you be looking to improve?’ ‘What research or discovery have you done to justify this request?’ Whilst these are all good questions to ask in general, they might not be relevant to every single task or request that comes your way. Perhaps someone is writing you a ticket that’s part of a wider initiative, that doesn’t need a whole separate set of discovery. Perhaps what they need is too small to be jumping through hoops for. Whilst you may have a large backlog to get through, putting up barriers to people only slows your collaboration, and may make it stall altogether. I have an initiative in discovery at the moment that I’d love to run a Salesforce report for, in order to better justify the investment. It would take about five minutes for someone who has a company account, but the team responsible want a full business case to raise a work request - and it’s probably not going to happen for something that small. If you ask people to fill out a set of compulsory questions every time they need to work with you, chances are you’ll end up with a backlog full of JIRA tickets populated with the same templated questions, and a few token lines shoved in which obfuscate the actual meaning behind the ticket.
However, there’s no reason to let your JIRA backlog become like the Wild West. Here are a few conventions I like which will help your stakeholders write good tickets that, for once, you won’t have to rewrite!
AS A… I WOULD LIKE… SO THAT
It’s a classic for a reason - it gets you (or your stakeholders) to focus on the user. The main issue with this format is that we often see the wrong person being put in the first position; any tickets which begin ‘AS A Product Manager’ are an automatic red flag! There are a few rare exceptions for updates to internal tools, but the clue is in the name: this needs to be a user-focused story. In general, this is a simple question format that gets you at least the core of what your stakeholder or user requires.
Context, Problem, Action
I find this especially helpful for tickets which come through as part of wider initiatives. It focuses you and your dev team on the work required, whilst not leaving them completely bereft of the background information. This might be as simple as saying ‘We previously tested X and got Y result, as a follow-up we’re going to implement Z’. Or, you can write something fuller for an individual story which needs its own context.
Acceptance Criteria
There are some occasions where detailed acceptance criteria are needed to make sure the ticket you’re writing is fully explicit. This might be needed if you have a task with a lot of edge cases, to make sure every path is covered. It might be useful if you have different markets with different needs, or very extensive and specific tracking. It’s probably a format that’s best handled with you or your engineering lead directly, rather than making your stakeholders fill this out, as they often need to be quite technical in order to be useful.
Do you like to use JIRA templates for your backlog? Let me know in the comments (so that I can disagree with you)!