To create a bug, a task OR to reopen a story?

Question

There is a question that me and my teammates are wondering about for a long long time.

Working with JIRA and product requirements we create epics, stories, tasks, sub-tasks and bugs, using almost all possible types of issues provided by JIRA.

Here is an issue we came across.

Imagine that we have an Epic with some standalone piece of functionality. And this epic is divided into Stories that represent even more detailed parts of that piece of functionality. Each story contains some information with acceptance criteria. Like a story "Make step 4 of the registration process with the ID" and criteria are "the user should be possible to add the Id number, to edit the Id, the field with ID should accept characters only and so on" (maybe we create the story in the wrong way and it is too big and should be divided into smaller parts....this is not the point). The developer takes the story and finishes it according to the criteria by creating sub-tasks in a story.

Now imagine that in the end of the development part when the story is ready for test the customer decides that they want to change something in that part of the functionality and some of the criteria change.

What should we do with the created and finished story and changed requirements?

Should we edit the story and criteria (write a comment to it) and reopen so that the developer makes all required changed? Or should we create a bug/task and close the story right away? Or close the story only after all changes in separate connected issues are fixed?

The same with the case when QA test a story and find out that some criteria were not fulfilled. Should they create a bug or reopen the story with the comment?

Any ideas and solutions...or personal experience? We fight all the time about this in our team so it would be really great to hear how you guys handle this stuff.

unknown · Answer

Thanks for your answer.
What I forgot to mention is that we stick to Kanban as Scrum with its sprints doesn't fit our processes.
We usually cannot say to the client that we cannot accept changes and fix all of that in latest sprints for many reasons. And they usually make small changes after and in progress of the story development like changing the icon, or a button, or making some UI changes which do not affect our time and other recourses much. All huge changes are postponed though or we shift the deadlines to the acceptable point. So we cannot shift all changes in requirements to latest implementation and deal with them later.

unknown · Answer

The customer decides that they want to change something in that part of the functionality and some of the criteria change. What should we do with the created and finished story and changed requirements?

* Stories are groomed, estimated, and accepted in the Backlog refinement by everybody including the product owner/delegate. Let's say "Story A" was for doing items 1, 2, and 3. If they want an additional 4, estimation is senseless at this point and your budget will suffer. What we do for this kind of situation is always leave the current Sprint as it is, work with the estimation/budget and any new features/changes will have to go in the next sprint (which will be groomed, estimated and accepted properly).

The same with the case when QA test a story and find out that some criteria were not fulfilled. Should they create a bug or reopen the story with the comment?

* This depends. If the bug is just a quick fix, do it right away. Just put the Story back to In Progress. If the bug affects a larger scope and affects other functionality (which takes time fixing), put it in the backlog that maybe promoted to a User Story later or fix it in another Sprint.

This is personal experience and this is what we are doing. We like to keep our Sprints small and acceptance criteria very simple. Our PO/PDO always decides if that Story actually meet their needs (after the demo), because for us, they are the only ones who decided if there's a bug or not, not the QA Testers.