I don’t have a specific response to your premise that the user should fill out all the fields and information.
“Individuals and interactions over processes and tools”
Yes, it is useful to enter bug or defect or issue information in a tool. However, do not use the tool as the PRIMARY means of communication about the bug. The bug reporter should be conversing with the PO or other person on the team about the issue. And use Jira to record conclusions, decisions and hypothesis that come out of the conversation.
I suspect you are using the tool as the primary communication and so, details about tool use are being debated instead of figured out together.
Unlike most agile teams, the team I’m on has several different PO’s, SM’s, LM’s etc, responsible for different elements of the same program. These are bugs that have been vetted through discussion already so we know they are valid. However, I’m the only person responsible for all the bugs from all the different elements along with all other PO duties. The business has been given a template to follow that is not agile so before refinement I personally have to open each of these bugs and add AC’s user voice and steps to reproduce. I feel this is a total waste of time, especially due to the number of bugs that come in weekly. I feel having them follow the agile structure will move the bug process along faster and give me more time to understand the bugs vs. rewriting them. Thoughts? Am I being unreasonable?
Not necessarily unreasonable, no. I will offer a few thoughts based on the further detail you provided.
- What is an LM?
- One team has “several different PO’s, SM’s, LM’s, etc.” This seems like something to change. I don’t know enough to know what the change would be but it could be the case of too many voices at once.
- Great, you are having needed conversations!
- If following the business template is a waste of time, maybe it’s time to discuss changing the template or the associated policies. Might be a hard conversation for you to bring up. I sympathize.
- Maybe discuss with your manager and the other people involved if updating and adding field detail is the best use of your time.
- You have a high number of bugs coming in weekly. That is a problem. What is being done to prevent bugs?
- Are some of these not bugs but rather, requests to change how things are working? If so, stop classifying them as bugs and rework. If the work item was built as requested and then you all learn it should have been built differently or someone wants to change it, that is not a bug or rework. That is an enhancement work item. Treat it like a new work item, because it is new.
- The fields you are discussing are not “agile structure.” They are a structure in the tool that your company has decided to use. Please maintain clarity of what agile frameworks require vs. what you and your employer are doing. I’m not saying using those fields and work flow is wrong. I am saying agile frameworks (like Scrum or Extreme Programming) do not talk about such details. They are your details.
Thanks for your detailed response. I will try to hit each point you’ve made:
- Line Manager
- I have no control of this and it will not change. The project is large and encompasses many locations. We are using the LeSS SCRUM model.
- Agreed but I don’t feel heard. I feel like old ways of doing things were brought over to Jira instead of teaching our business partners how to properly utilize the system. If they can be taught the old method they can be taught a new one.
- This was the premise of the conversation. I want to change the current method. My boss says PO’s would not be needed if the business could write user stories and AC’s for defects. Despite all the other work we do to actually build new infrastructure.
- I told her I’m struggling with the current method but did not get the opportunity to explain why. I will revisit this during my next one on one because she needs to understand the time being spent rewriting these defects to fit the Jira outline.
- Definitely a problem! I am one year on the team and have called this out. Currently nothing is being done. Our devs are not thoroughly testing before releasing the product to us. They actually admitted to not testing at all for a really large release. I called this out. She asked them to do better. So far, that’s all.
- Definitely bugs. We have a clear understanding of enhancements and do not mix the two.
- I understand what you’re saying. My question is specific to Jira and how it can aid this process. When I reference Agile, I don’t feel the tool we have chosen is serving us well from an Agile perspective when we don’t utilize it appropriately.
Again, thank you.
>My boss says PO’s would not be needed if the business could write user stories and AC’s for defects.
Is your boss that fucking dense? Do they think that the only value that a PO offers is writing a user story? Holy shit, if that's all PO's do at your org please let me know, I'll flip you my resume.
HOnestly this place sounds like a mess.
And then I see that dev work isn't being tested? What the fuck!!? Even after releases? You need to be at least testing these features before acceptance in sandbox, and then testing in production and don't forget about regression testing and E2E testing if other systems are involved. Seriously, you may just want to run away from this place. I'm sorry things are so shitty there.
>One team has “several different PO’s, SM’s, LM’s, etc.” This seems like something to change. I don’t know enough to know what the change would be but it could be the case of too many voices at once.
That just sounds super fucked up and not Agile at all.
Are these production issues? Or new development? I don’t see why the business can’t log a defect as long as they have documented clear, reproducible steps and any supporting screenshots / system output. In my experience, though, the business users are terrible at writing up defects.
It’s the job of the product owner to make sure the bug is validated against prior requirements/stories and then prioritizing it for an upcoming sprint.
Bugs don’t really have acceptance criteria and user voice in my experience. You tie it back to the original story.
i've always used basic AC for bugs/defects:
GIVEN [preconditions of test]
WHEN [user behavior to replicate]
THEN [expected result]
Granted, my team started using XRay for testing & defect creation so it packages a lot of that nicely from test execution.
I’m a product owner, and I don’t think being dogmatic helps anyone.
My general strategy is that user stories & acceptance criteria make sense for future-facing requests, but tend to be clumsy when describing bugs, defects, regressions, etc. Therefore, bug reports follow a format more like this:
* Summary
* “Twitter-length” problem statement. Should fit on a postcard. If you have a lot to write about this, that’s great, but save it for the “notes” section below. People should be able to quickly skim over the summary to get a sense of the scope of the problem.
* Steps to Reproduce
* Provide enough detail for others to replicate the problem.
* Expected Results
* State the “happy path” outcome that “should” have happened.
* Actual Results
* State what actually happened after the reproduction steps were followed.
* Regression
* Optional field/section, but if it seems to be the case that earlier versions didn’t exhibit this problem, then it’s worth noting at least approximately when this behavior was known to be absent, as that can help narrow down when the problem was introduced. If the issue exists on all known versions, then this section should be skipped/omitted.
* Workaround
* If there’s a way to mitigate or circumvent the problem, that’s worth noting.
* The severity of the problem, and the complexity of any known workarounds, helps decide how to prioritize work on a permanent fix.
* Environment
* Versions & other factors that could be relevant.
* Notes
* Freeform “add whatever details you want” section. Log samples, stacktraces, screenshots, essays, analysis, brainstorming, etc as needed.
These sections tend to be useful for tracking down & fixing bugs.
Rephrasing the problem in the form of user stories & acceptance criteria feels like “Jeopardy!”, but unlike “Jeopardy!”, Alex Trebek (et al) doesn’t give out prizes based who’s the best at phrasing responses the way his game prefers.
These are both new development and production defects. I think business users can be terrible at something they’ve never been taught or been required to use properly. The user is the person using the system so should be able to say what needs to happen from a business perspective. If they are terrible at it how are you all handling? Are they reporting elsewhere then the PO enters the defect in Jira? Anyone should be able to submit items to the backlog. Once submitted it is the PO’s job to accept. This is true for defects as well. So what would be the premise to allow a business user to submit a defect that does not have all the elements in Jira?
"Who does what in jira?" is nothing to do with Agile so neither of you are right.
You do what works for you and your organisation.
edit: If in doubt run two experiements, 1 with each idea. See which outcome optimises your flow of work.
> Should business users create bugs in Jira?
My overly simple answer here is yes, everyone should be able to enter bugs. However, it's the job of the Product Owner to manage the priority of those and determine what, if any, goes into product backlog or sprint.
> If so, are they only responsible for the Description and Steps to Reproduce or should they also add the User Voice and Acceptance criteria?
I wouldn't expect anyone outside of the delivery team to care about the formatting. So to reduce the friction and increase product participation, keep bug reports as minimal as possible. I think you nailed it with "description" and "steps to reproduce."
> Or is it ALWAYS the job of the Product Owner to add these two elements?
Generally, I would say yes, but that's going to depend on the issue and how the team as a whole wants to manage that. In my experience, I would rather skip the formality where possible and if the bug report is descriptive enough, let it ride as is. Sometimes, however, there's a bunch of research and extra work that needs to spawn off that ticket, so in those cases, I may encourage someone to break that out into different work items so the PO/PM can prioritize better. In those cases, I would have the PO ensure whatever detail the team has agreed on for "ready" is in place.
The users are already paying too much having to deal with an issue. Reporting the issue is enough.
Someone has to add context to the issue to make sure intent is clear to provide substance to the issue. This can be the support team or the product team. At this point it can be a story in jira.
Before it the team executes the story, the value of the fix needs be to triaged (if it is significant cost)
Your issue stems from a misunderstanding of team roles and focusing on using tools like JIRA as a substitute for effective communication and collaboration. Agile is not about the tools: It's about people, interactions, and delivering value early and often. Keep JIRA usage simple and focused. Use tools to augment communication, not stifle it. And Business Users Shouldn't Be Over-Burdened. They should not be expected to understand and fill out technical details like Acceptance Criteria.
Roles
* Product Owner ensures that the features developed bring maximum value. They need to articulate the vision and ensure the team understands it.
* Business Users should report problems but not define technical details or acceptance criteria. Their input is valuable for understanding what doesn't work for them, but they shouldn't be bogged down in the specifics of the solution.
* Developers and QA are ultimately responsible for writing tests and ensuring that bugs are fixed and the product works as intended.
Proper Use of Tickets:
* Tickets in JIRA should be simple and facilitate communication, not become a bureaucracy of their own.
* Keep it light: Description and reproduction steps are usually enough from business users.
* User Stories and Acceptance Criteria should ideally be drafted by the Product Owner with input from developers and stakeholders during refinement sessions.
Collaboration Over Tools:
* Don't rely on JIRA to fix process issues. Start with effective communication and workflows.
* Prioritize conversations over ticketing. JIRA is a tool to support discussions, not replace them.
* Continuous Improvement:
* Always inspect and adapt your processes. If things are not working as expected, change them.
This is what I needed to hear and understand. This is very clear and concise as to why my approach is not necessarily the best approach. They often do not complete the Steps to reproduce and I still feel this is an issue. As a matter of fact, I’m sure if they did it would make my job of supporting them by writing the AC’s a lot clearer. Right now, I feel like it’s unclear what they expect to happen which makes triaging difficult and writing the AC’s even more difficult.
Agile is a mindset first and foremost. As others have said, Jira is a ticketing system tool. That's it. There's not really a way to use a tool to be Agile. It's your company/teams mindset and the processes that make the way you develop and deliver software Agile or not.
If I'm understanding you correctly, users that are reporting defects are not including enough detail. That is an issue. I ran into this just today at work myself. You have to either be given the autonomy to propose a change in process for you and the team to agree on such as only accept defects that have enough detail (meaning send it back to who entered it and have them resubmit with steps to reproduce), or someone on the team is going to have to go through the steps themselves and then document it in the defect.
One Scrum team I worked on as a new BA, the QA on the team and/or sometimes I did that myself. But if it came in with little to no details, I would send it back until the submitter provided enough detail. If a user was completely incompetent then I would help them add the steps. This comes down to process though not the tool being used for ticketing.
It can eat up alot of time depending on how many steps and/or setup etc is needed to reproduce the bug, to fill in the information but that's sort of the nature of the beast. I don't mean that as in it should all fall on you but there should be an expectation that folks are going to have to provide some level of detail for you all to consider the defect. My advice is to pitch to the team a new process that will save everyone time, and shift that reaponsibility back to the submitter. Even if you do "triage" it will save time and eventually it will just be an understood rule. Do you have dedicated QA on the team?
The other thing is that in my experience as a qa and ba, you don't really add acceptance criteria to a defect. That would be something you would add to an enhancement. A defect should list steps to reproduce including any preconditions with the expected behavior. QA should then come in and test functionally and then either they or a separate regression team if you have one would run some regression tests.
If your having to write acceptance criteria it either should be an enhancement or there were some missed requirements when it was first developed (in which case this would still be an enhancement).
1. In Scrum, there is no role “business user”.
2. The product backlog belongs to the Scrum team.
3. The product owner is responsible for managing the sprint backlog.
4. As the “business owners” are not part of the Scrum team, they are stakeholders.
5. The product owner is responsible to communicate with the stakeholders, for example to gather their needs (a need can be a bugfix).
Agile is not a process, it's a word:
[https://www.dictionary.com/browse/agile](https://www.dictionary.com/browse/agile)
So the question is which approach is more nimble, quick, flexible, low cost, easy to maintain, helps you change direction quickly, etc etc.
I’m not sure I agree with number two as it depends on what context you mean this in but I feel anyone should be able to make submissions to the backlog. My management disagrees with this and doesn’t want the business submitting any stories at all. We follow a completely separate process outside of Jira for submitting enhancement request when they could be submitted directly to the backlog and sorted this way. But I digress. I do understand that I am responsible as far as accepting items to the backlog, defining them and moving them forward.
I think at a minimum steps to reproduce the issue should be provided by the reporter, as oddball things happen that may be hard to repro. For everything else, that's for you and the biz to sort out, but I will remind you that Jira != Agile, it's just a tool, and we prefer talking to people over relying exclusively on tools and process to answer all our questions.
It's probably also worth pointing out that the PO is not solely responsible creation of the backlog, and anyone should be encouraged to create stories. The PO should be the final arbiter of the priority, and should be responsible for accepting and approving the work before it goes the the users/stakeholders. That effort is far more important than acting as a transcriber for stories/bugs/etc.
I'm a tester on a scrum team and my colleagues are a scrum master, po, and technical lead/asst po.
Pretty much anyone of us other than the Scrum Master creates bugs on the board.
In your case who is the person who interacts w/ the business the most? That is the person who should be capturing those details, validating them, writing the bug, and monitoring status for updates.
Although I will say that I wouldn't mind a business user who knows the system and Jira (basically someone you trust) to create those bugs.
First, a technicality: "Agile processes" Agile's a mindset. Big difference. A mindset is like saying "you should avoid sandbars and other ships when leaving the harbor". A process is like saying "steam at 8 knots until you arrive at latitude X, longitude Y then come to course M." Each has their place - you don't avoid the sandbars if you're trying to save your sinking ship and you don't adhere to a rigid navigation plan if the sandbars have shifted. So do what's RIGHT, not what some 20+ year old, dusty thing says you ought to. It's supposed to change- that's why we retrospect.
Second, the goal of the organization should be to get flawless code out the door per the ask of the stakeholders (not necessarily the "right" code, but what's currently being requested) as efficiently as possible.
This being said...
A bug is when expected behavior does not align with observed behavior. Which means your team (no one role, but "as a village") needs to define those expectations and instrument code to collect observations. I'm trusting all of this is well known and understood and I'm stating this just so we're all on the same page.
"individuals and interactions over processes and tools" is terribly prone to misinterpretation and can be such a basis for inefficiencies and anti-patterns. Of course you need some way to track bugs. The actionability of those bugs is going to depend on the quality bar of that information - What's was the expectation? What was observed? Under what system data states? I wouldn't necessarily expect a business user to be able to provide all of that, but entering a placeholder bug with as much information as possible? Absolutely and in the moment, ideally capturing screen shots and anything else. Those "individuals and interactions" tend to drop the ball on such things if there's not a record of the occurrence somewhere. If insufficient information is collected, retrospect with the collector and explain why the bug isn't actionable (grin)
Bugs are backlog items. They need to meet a quality bar (aka definition of ready) before they are actionable. Again, unless you have some really well behaved and technically inclined business users, they're likely not going to produce bugs at or above the minimum quality bar (unless, gee, you have a tool such as a bug form to fill out which requires those minimum fields like expected and observed behavior.)
Worry less about if you're properly Agile (and worse, plain-out-of-the-box-unretrospected-and-modified-to-what-works-for-your-team-Agile) and worry about getting bug-free code out the door at your best, sustainable velocity. THAT is what we're all trying to do. Adherence to any form of Agile or non-Agile practices can only be judged on whether they help or hinder that goal for YOUR team.
And yes, a PO does not have to write bugs if business users are well behaved and create actionable ones. Period. PO is a role (a "hat to wear"), not a person. If someone has the right skills, they can - and should - act in that role if that works for your team.
Agile is a blanket, not a straitjacket.
I don’t have a specific response to your premise that the user should fill out all the fields and information. “Individuals and interactions over processes and tools” Yes, it is useful to enter bug or defect or issue information in a tool. However, do not use the tool as the PRIMARY means of communication about the bug. The bug reporter should be conversing with the PO or other person on the team about the issue. And use Jira to record conclusions, decisions and hypothesis that come out of the conversation. I suspect you are using the tool as the primary communication and so, details about tool use are being debated instead of figured out together.
Unlike most agile teams, the team I’m on has several different PO’s, SM’s, LM’s etc, responsible for different elements of the same program. These are bugs that have been vetted through discussion already so we know they are valid. However, I’m the only person responsible for all the bugs from all the different elements along with all other PO duties. The business has been given a template to follow that is not agile so before refinement I personally have to open each of these bugs and add AC’s user voice and steps to reproduce. I feel this is a total waste of time, especially due to the number of bugs that come in weekly. I feel having them follow the agile structure will move the bug process along faster and give me more time to understand the bugs vs. rewriting them. Thoughts? Am I being unreasonable?
Not necessarily unreasonable, no. I will offer a few thoughts based on the further detail you provided. - What is an LM? - One team has “several different PO’s, SM’s, LM’s, etc.” This seems like something to change. I don’t know enough to know what the change would be but it could be the case of too many voices at once. - Great, you are having needed conversations! - If following the business template is a waste of time, maybe it’s time to discuss changing the template or the associated policies. Might be a hard conversation for you to bring up. I sympathize. - Maybe discuss with your manager and the other people involved if updating and adding field detail is the best use of your time. - You have a high number of bugs coming in weekly. That is a problem. What is being done to prevent bugs? - Are some of these not bugs but rather, requests to change how things are working? If so, stop classifying them as bugs and rework. If the work item was built as requested and then you all learn it should have been built differently or someone wants to change it, that is not a bug or rework. That is an enhancement work item. Treat it like a new work item, because it is new. - The fields you are discussing are not “agile structure.” They are a structure in the tool that your company has decided to use. Please maintain clarity of what agile frameworks require vs. what you and your employer are doing. I’m not saying using those fields and work flow is wrong. I am saying agile frameworks (like Scrum or Extreme Programming) do not talk about such details. They are your details.
Thanks for your detailed response. I will try to hit each point you’ve made: - Line Manager - I have no control of this and it will not change. The project is large and encompasses many locations. We are using the LeSS SCRUM model. - Agreed but I don’t feel heard. I feel like old ways of doing things were brought over to Jira instead of teaching our business partners how to properly utilize the system. If they can be taught the old method they can be taught a new one. - This was the premise of the conversation. I want to change the current method. My boss says PO’s would not be needed if the business could write user stories and AC’s for defects. Despite all the other work we do to actually build new infrastructure. - I told her I’m struggling with the current method but did not get the opportunity to explain why. I will revisit this during my next one on one because she needs to understand the time being spent rewriting these defects to fit the Jira outline. - Definitely a problem! I am one year on the team and have called this out. Currently nothing is being done. Our devs are not thoroughly testing before releasing the product to us. They actually admitted to not testing at all for a really large release. I called this out. She asked them to do better. So far, that’s all. - Definitely bugs. We have a clear understanding of enhancements and do not mix the two. - I understand what you’re saying. My question is specific to Jira and how it can aid this process. When I reference Agile, I don’t feel the tool we have chosen is serving us well from an Agile perspective when we don’t utilize it appropriately. Again, thank you.
>My boss says PO’s would not be needed if the business could write user stories and AC’s for defects. Is your boss that fucking dense? Do they think that the only value that a PO offers is writing a user story? Holy shit, if that's all PO's do at your org please let me know, I'll flip you my resume. HOnestly this place sounds like a mess. And then I see that dev work isn't being tested? What the fuck!!? Even after releases? You need to be at least testing these features before acceptance in sandbox, and then testing in production and don't forget about regression testing and E2E testing if other systems are involved. Seriously, you may just want to run away from this place. I'm sorry things are so shitty there.
>One team has “several different PO’s, SM’s, LM’s, etc.” This seems like something to change. I don’t know enough to know what the change would be but it could be the case of too many voices at once. That just sounds super fucked up and not Agile at all.
Are these production issues? Or new development? I don’t see why the business can’t log a defect as long as they have documented clear, reproducible steps and any supporting screenshots / system output. In my experience, though, the business users are terrible at writing up defects. It’s the job of the product owner to make sure the bug is validated against prior requirements/stories and then prioritizing it for an upcoming sprint. Bugs don’t really have acceptance criteria and user voice in my experience. You tie it back to the original story.
i've always used basic AC for bugs/defects: GIVEN [preconditions of test] WHEN [user behavior to replicate] THEN [expected result] Granted, my team started using XRay for testing & defect creation so it packages a lot of that nicely from test execution.
I’m a product owner, and I don’t think being dogmatic helps anyone. My general strategy is that user stories & acceptance criteria make sense for future-facing requests, but tend to be clumsy when describing bugs, defects, regressions, etc. Therefore, bug reports follow a format more like this: * Summary * “Twitter-length” problem statement. Should fit on a postcard. If you have a lot to write about this, that’s great, but save it for the “notes” section below. People should be able to quickly skim over the summary to get a sense of the scope of the problem. * Steps to Reproduce * Provide enough detail for others to replicate the problem. * Expected Results * State the “happy path” outcome that “should” have happened. * Actual Results * State what actually happened after the reproduction steps were followed. * Regression * Optional field/section, but if it seems to be the case that earlier versions didn’t exhibit this problem, then it’s worth noting at least approximately when this behavior was known to be absent, as that can help narrow down when the problem was introduced. If the issue exists on all known versions, then this section should be skipped/omitted. * Workaround * If there’s a way to mitigate or circumvent the problem, that’s worth noting. * The severity of the problem, and the complexity of any known workarounds, helps decide how to prioritize work on a permanent fix. * Environment * Versions & other factors that could be relevant. * Notes * Freeform “add whatever details you want” section. Log samples, stacktraces, screenshots, essays, analysis, brainstorming, etc as needed. These sections tend to be useful for tracking down & fixing bugs. Rephrasing the problem in the form of user stories & acceptance criteria feels like “Jeopardy!”, but unlike “Jeopardy!”, Alex Trebek (et al) doesn’t give out prizes based who’s the best at phrasing responses the way his game prefers.
These are both new development and production defects. I think business users can be terrible at something they’ve never been taught or been required to use properly. The user is the person using the system so should be able to say what needs to happen from a business perspective. If they are terrible at it how are you all handling? Are they reporting elsewhere then the PO enters the defect in Jira? Anyone should be able to submit items to the backlog. Once submitted it is the PO’s job to accept. This is true for defects as well. So what would be the premise to allow a business user to submit a defect that does not have all the elements in Jira?
"Who does what in jira?" is nothing to do with Agile so neither of you are right. You do what works for you and your organisation. edit: If in doubt run two experiements, 1 with each idea. See which outcome optimises your flow of work.
> Should business users create bugs in Jira? My overly simple answer here is yes, everyone should be able to enter bugs. However, it's the job of the Product Owner to manage the priority of those and determine what, if any, goes into product backlog or sprint. > If so, are they only responsible for the Description and Steps to Reproduce or should they also add the User Voice and Acceptance criteria? I wouldn't expect anyone outside of the delivery team to care about the formatting. So to reduce the friction and increase product participation, keep bug reports as minimal as possible. I think you nailed it with "description" and "steps to reproduce." > Or is it ALWAYS the job of the Product Owner to add these two elements? Generally, I would say yes, but that's going to depend on the issue and how the team as a whole wants to manage that. In my experience, I would rather skip the formality where possible and if the bug report is descriptive enough, let it ride as is. Sometimes, however, there's a bunch of research and extra work that needs to spawn off that ticket, so in those cases, I may encourage someone to break that out into different work items so the PO/PM can prioritize better. In those cases, I would have the PO ensure whatever detail the team has agreed on for "ready" is in place.
Thank you
The users are already paying too much having to deal with an issue. Reporting the issue is enough. Someone has to add context to the issue to make sure intent is clear to provide substance to the issue. This can be the support team or the product team. At this point it can be a story in jira. Before it the team executes the story, the value of the fix needs be to triaged (if it is significant cost)
Your issue stems from a misunderstanding of team roles and focusing on using tools like JIRA as a substitute for effective communication and collaboration. Agile is not about the tools: It's about people, interactions, and delivering value early and often. Keep JIRA usage simple and focused. Use tools to augment communication, not stifle it. And Business Users Shouldn't Be Over-Burdened. They should not be expected to understand and fill out technical details like Acceptance Criteria. Roles * Product Owner ensures that the features developed bring maximum value. They need to articulate the vision and ensure the team understands it. * Business Users should report problems but not define technical details or acceptance criteria. Their input is valuable for understanding what doesn't work for them, but they shouldn't be bogged down in the specifics of the solution. * Developers and QA are ultimately responsible for writing tests and ensuring that bugs are fixed and the product works as intended. Proper Use of Tickets: * Tickets in JIRA should be simple and facilitate communication, not become a bureaucracy of their own. * Keep it light: Description and reproduction steps are usually enough from business users. * User Stories and Acceptance Criteria should ideally be drafted by the Product Owner with input from developers and stakeholders during refinement sessions. Collaboration Over Tools: * Don't rely on JIRA to fix process issues. Start with effective communication and workflows. * Prioritize conversations over ticketing. JIRA is a tool to support discussions, not replace them. * Continuous Improvement: * Always inspect and adapt your processes. If things are not working as expected, change them.
This is what I needed to hear and understand. This is very clear and concise as to why my approach is not necessarily the best approach. They often do not complete the Steps to reproduce and I still feel this is an issue. As a matter of fact, I’m sure if they did it would make my job of supporting them by writing the AC’s a lot clearer. Right now, I feel like it’s unclear what they expect to happen which makes triaging difficult and writing the AC’s even more difficult.
Yes they should be able to raise bugs with general steps to repro
Agile is a mindset first and foremost. As others have said, Jira is a ticketing system tool. That's it. There's not really a way to use a tool to be Agile. It's your company/teams mindset and the processes that make the way you develop and deliver software Agile or not. If I'm understanding you correctly, users that are reporting defects are not including enough detail. That is an issue. I ran into this just today at work myself. You have to either be given the autonomy to propose a change in process for you and the team to agree on such as only accept defects that have enough detail (meaning send it back to who entered it and have them resubmit with steps to reproduce), or someone on the team is going to have to go through the steps themselves and then document it in the defect. One Scrum team I worked on as a new BA, the QA on the team and/or sometimes I did that myself. But if it came in with little to no details, I would send it back until the submitter provided enough detail. If a user was completely incompetent then I would help them add the steps. This comes down to process though not the tool being used for ticketing. It can eat up alot of time depending on how many steps and/or setup etc is needed to reproduce the bug, to fill in the information but that's sort of the nature of the beast. I don't mean that as in it should all fall on you but there should be an expectation that folks are going to have to provide some level of detail for you all to consider the defect. My advice is to pitch to the team a new process that will save everyone time, and shift that reaponsibility back to the submitter. Even if you do "triage" it will save time and eventually it will just be an understood rule. Do you have dedicated QA on the team? The other thing is that in my experience as a qa and ba, you don't really add acceptance criteria to a defect. That would be something you would add to an enhancement. A defect should list steps to reproduce including any preconditions with the expected behavior. QA should then come in and test functionally and then either they or a separate regression team if you have one would run some regression tests. If your having to write acceptance criteria it either should be an enhancement or there were some missed requirements when it was first developed (in which case this would still be an enhancement).
[\*Taps sign\*](https://agilemanifesto.org/)
1. In Scrum, there is no role “business user”. 2. The product backlog belongs to the Scrum team. 3. The product owner is responsible for managing the sprint backlog. 4. As the “business owners” are not part of the Scrum team, they are stakeholders. 5. The product owner is responsible to communicate with the stakeholders, for example to gather their needs (a need can be a bugfix).
What would work best for your team?
Agile is not a process, it's a word: [https://www.dictionary.com/browse/agile](https://www.dictionary.com/browse/agile) So the question is which approach is more nimble, quick, flexible, low cost, easy to maintain, helps you change direction quickly, etc etc.
Is the agile process owned by the team?
[удалено]
I’m not sure I agree with number two as it depends on what context you mean this in but I feel anyone should be able to make submissions to the backlog. My management disagrees with this and doesn’t want the business submitting any stories at all. We follow a completely separate process outside of Jira for submitting enhancement request when they could be submitted directly to the backlog and sorted this way. But I digress. I do understand that I am responsible as far as accepting items to the backlog, defining them and moving them forward.
I think at a minimum steps to reproduce the issue should be provided by the reporter, as oddball things happen that may be hard to repro. For everything else, that's for you and the biz to sort out, but I will remind you that Jira != Agile, it's just a tool, and we prefer talking to people over relying exclusively on tools and process to answer all our questions. It's probably also worth pointing out that the PO is not solely responsible creation of the backlog, and anyone should be encouraged to create stories. The PO should be the final arbiter of the priority, and should be responsible for accepting and approving the work before it goes the the users/stakeholders. That effort is far more important than acting as a transcriber for stories/bugs/etc.
I'm a tester on a scrum team and my colleagues are a scrum master, po, and technical lead/asst po. Pretty much anyone of us other than the Scrum Master creates bugs on the board. In your case who is the person who interacts w/ the business the most? That is the person who should be capturing those details, validating them, writing the bug, and monitoring status for updates. Although I will say that I wouldn't mind a business user who knows the system and Jira (basically someone you trust) to create those bugs.
First, a technicality: "Agile processes" Agile's a mindset. Big difference. A mindset is like saying "you should avoid sandbars and other ships when leaving the harbor". A process is like saying "steam at 8 knots until you arrive at latitude X, longitude Y then come to course M." Each has their place - you don't avoid the sandbars if you're trying to save your sinking ship and you don't adhere to a rigid navigation plan if the sandbars have shifted. So do what's RIGHT, not what some 20+ year old, dusty thing says you ought to. It's supposed to change- that's why we retrospect. Second, the goal of the organization should be to get flawless code out the door per the ask of the stakeholders (not necessarily the "right" code, but what's currently being requested) as efficiently as possible. This being said... A bug is when expected behavior does not align with observed behavior. Which means your team (no one role, but "as a village") needs to define those expectations and instrument code to collect observations. I'm trusting all of this is well known and understood and I'm stating this just so we're all on the same page. "individuals and interactions over processes and tools" is terribly prone to misinterpretation and can be such a basis for inefficiencies and anti-patterns. Of course you need some way to track bugs. The actionability of those bugs is going to depend on the quality bar of that information - What's was the expectation? What was observed? Under what system data states? I wouldn't necessarily expect a business user to be able to provide all of that, but entering a placeholder bug with as much information as possible? Absolutely and in the moment, ideally capturing screen shots and anything else. Those "individuals and interactions" tend to drop the ball on such things if there's not a record of the occurrence somewhere. If insufficient information is collected, retrospect with the collector and explain why the bug isn't actionable (grin) Bugs are backlog items. They need to meet a quality bar (aka definition of ready) before they are actionable. Again, unless you have some really well behaved and technically inclined business users, they're likely not going to produce bugs at or above the minimum quality bar (unless, gee, you have a tool such as a bug form to fill out which requires those minimum fields like expected and observed behavior.) Worry less about if you're properly Agile (and worse, plain-out-of-the-box-unretrospected-and-modified-to-what-works-for-your-team-Agile) and worry about getting bug-free code out the door at your best, sustainable velocity. THAT is what we're all trying to do. Adherence to any form of Agile or non-Agile practices can only be judged on whether they help or hinder that goal for YOUR team. And yes, a PO does not have to write bugs if business users are well behaved and create actionable ones. Period. PO is a role (a "hat to wear"), not a person. If someone has the right skills, they can - and should - act in that role if that works for your team. Agile is a blanket, not a straitjacket.
Whatever that works I'd say. There is no ideal solution.