Whose responsibility is to add stories to JIRA (or other issue-tracking software)?

Question

This might seem as odd question, but moving from business to business I'm still puzzled as to whose responsibility it is to add stories to JIRA (or other issue-tracking software), as well be responsibility for the Agile board in general.

The person in question of course is part of all business and development (tech debts, tech improvements) talks, documenting everything and setting up Spikes, Epics, Stories etc. Making sure all developers are OK to work and have no impediments, sounds like a Scrum Master. Taking this into account what about Kanban, other Agile frameworks?

My experience shows Business Analyst doing this too.

Answer 1

There are two main ways I know of that work.

First, a possible answer is 'The Product Owner' (or someone/someones with the same responsibilities). Namely, someone who knows the customer's requirements.

The second option is to allow anyone to add Stories, but to have the Product Owner (or equivalent) vet them.

Of course, that's only for Stories (requirements that provide direct value to the customer). Tasks are the domain of the developers', as they're often the only ones to understand them.

The first step is to differentiate between Stories and Tasks. If it's a developer Task, then non-developers don't need to understand it. "Refactor FizzRepository to be compliant with Liskov substitution principle" is not going to be understood by a non-developer, and it doesn't have to be.

Stories, however, are about providing direct business value to the customer, and thus must be understandable to the customer. While having available guidelines for Story creation might help (such as the INVEST method) may assist, in the end they need to be vetted by someone who either is the customer, or whose job is to understand customers' needs.

Answer 2

Feeding Stories related to Business requirements is responsibility of Business Analyst / Product Owner.

Feeding Technical stories / Spikes to achieve the Business requirements is responsibility of the team.

Answer 3

Scrum

Also, most frameworks out there use this same approach. I'll point out the differences in Kanban and XP below. The scrum guide says:

"The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering."

Most interpretations I've heard of this is more like "accountable" in RACI. The product owner makes sure it gets done and that it is ordered properly. They may or may not be the ones to write the backlog items, but they should be able to speak to them and explain to stakeholders their value.

XP

In XP, the product owner is an actual customer. In XP teams, I see almost all items in the backlog being very focused on customer needs, and so that customer is almost always the one writing them.

Kanban

There is some nuance here (Kanban is not a methodology, it's a process optimization tool) so there isn't actually a right answer, but in most Kanban teams I've worked with, they either have a product owner like in Scrum or (especially in operations teams) they have some work intake funnel. In the later case, the person filing the request is often writing the backlog item themselves or working with a team member to make sure it's clear. Think of when you file a support ticket. Either you write it yourself or you call support and they write one from their conversation with you.

Business Analysts

The problem I've seen with putting this responsibility on the Business Analyst is that there is a healthy tension between the roles of Product Owner and Delivery Team. The product owner orders the backlog, identifying what items are most valuable to do first. The team determines how to implement those items. Traditionally, many BA's are tasked with doing both. This loses that tension. I usually ask BA's to try to pick a role to focus in and most enjoy the problem solving aspects of the work and end up in the team.