The feature is already implemented in Kunagi. See, for example iss836. I created a Story from that Issue yesterday, and in the Statement, it says I did (this Statement was created automatically). Additionally, if I display the Change History from within Kunagi, I can also see which Story was created and when.

Does that answer your question?

Yes, I can convert issues into stories. But my request is different. Say, I have a story S1-Create login page. Then in testing we find an issue in that story, so we create issue (say iss1), but we can't get to that issue in the sprint. Thus the story is also not completed in the sprint. As time passes we might have more of such stories and issues handing. Down the line, we don't know that iss1 was created for S1. I would like to relate an issue created while testing a story back to that story.

So that we know when a developer fixed an issue, what is the story that we need to retest.

Okay, I see. The problem here is that you are using Issues not as intended. If you have a Story in a current Sprint, its scope should be both development and testing. This has nothing to do with Kunagi in particular, it's rather the agile principles upon the design choice is based.

So, if you have bugs during development, you should not create Issues for those bugs. There are a few reasons for this:

• As you have seen, it's hard to keep track of such Issues.
• While a Story is in development, it has not yet been delivered (as a product increment). Thus, a bug tracker (or, our Issue system, respectively) cannot necessarily refer to that feature.
• The workflow for Issues (in general) does not fit the use case. What you are looking for are rather Bugs, not Issues. So to create an Issue for a Story, you need to post an Issue and convert it to a bug (always). Converting it to another Story or to an Idea or Closing it right away are options that do not make much sense.

When I review Stories, I usually comment on it if I find bugs. A Team Member can then read the comment and create a Task. Here, the Issue in your use case is represented by a Task in the Story, can be easily affiliated with it and it is also clear, when a Story is ready for review again.

Let me say one more thing. We are currently testing an alternative workflow for Bugs that might give better hints on how Issues are meant to be used. Also, we should probably get arount to some kind of documentation to avoid confusion for certain features that are not really self-explanatory.

Thanks for explaining the detail. I agree with what you say. We will try to change our way of using the tool. :-)

Thanks,
Aruna.

This is wonderful comments. cleared a lot.

Like the suggestion of creating a bug as a task under the story, that helps the PO to know if a story is really done or not.
The burn-down might show a spike, but that should be a good indicator to discuss during retrospective