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.

Answer 4

I want to start some thoughts on this question.

When does text become a story?

• When the Product Owner (PO) accepted it?
• When did the Description of Requirements accept it?
• When did the idea emerge somewhere? ...

The idea behind these questions is that any user should be able to state a request, an idea, feedback, ... and therefore create an item.

The PO organizes the backlog, and works with the team to make this item ready to be considered as a "ready" story.

It's up to the Team to decide when an item enters the Product Backlog. And as soon as it enters, it is then taken care of by the PO with a view to considering it in a sprint backlog.

And again, what I'm saying is MY point of view; the Team is self-organized, it's up to them to decide, to adjust this kind of thinking so that it has its own organization.

But as a result, JIRA, which is just the tool, will have to be configured according to the organization chosen by the Team.

All the cards can change in nature, the nature of the item (Issue) will then determine the possible states and properties of the item.

Passages from one state to another will determine the workflow of items of this type.

And finally, we ask the PO to prioritize the Backlog, people to give feedback, ... but should they be the operators / encoders in JIRA?

If we are in a system where everyone follows the rules, then it's like a wiki, everyone has all the rights and everyone does what they have the right to do. This greatly simplifies the rights management of the JIRA project.

---

• Let everybody create items (type request/ask/idea/need/feedback/...)
• Let decide the /team "how to convert them to stories"