Hello group,
I am working in an organization where I am setting the Quality Assurance Team right from the beginning.
We are using Jira Cloud software and the main challenge I have is to manage the adhoc change request from Customer.
Let me explain a bit more about my actual situation. We follow Scrum Project model and create Epic, User stories, Sub task. Bug, Test etc. But we get lot of changes in the original requirement even when the Customer are just near to complete their UAT test phase.
Do I need to opt for the Issue Type "Change" and create this Change type under the Epic for every Requirement change we get? or do I need to modify the existing User Stories "Acceptance criteria"? The Challenge here is to consider the steps to follow :
1) When User Story is in-progress with Development or Test, how to accommodate the adhoc change from Customer?
2) When User story is completed , how to manage the adhoc change request from Customer?
This seems more like a process question/issue than a tooling question to be perfectly honest. Jira is very flexible when it comes to setting up issue types with associated workflows to handle any approach you would like to implement.
However, if you use scrum as your methodology, there is a smell about changes to original requirements during stories in an ongoing sprint. Assuming that a sprint runs for 2 weeks, you would validate the stories in that sprint before committing to development together with the customer, no? The Definition of Done of stories committed in your current sprint should be clear and validated before you start working on them. If they are not clear, don't start (sounds a bit oversimplified maybe, but it's a great rule of thumb to go by).
If you can enforce that way of working upon your team and the collaboration with your customer, implementing change can become as simple as adding new stories.
I am assuming now that all this is part of new feature development. In case you are already in support/maintenance mode, it would make more sense to use a Service desk to capture bugs, feature and change requests first. After assessing those, you can create linked issues for the development team. And those can then be incorporated in the normal planning flow, along with new features.
For some more background tips on Jira and scrum, have a look at Atlassian's Agile Coach documentation. There's a ton of resources available on the net on agile, scrum etc, but the Agile Coach relates to your toolset as well - as part of agile operations.
Thank you for your response.
The Model we are following is Scrum. My point was to know about issue type as "Change" in Jira, to understand the difference between Change against Epic & US.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.