What we had in mind when creating the workflow as it is concerning Stories, are mainly two things:

1. There is a clear distinction between the Product Owner's role (creating Stories) and the Development Team (estimating and implementing Stories).
2. Stories are always tackled during Sprints and never done "on the side".

Both are Scrum principles and I have the feeling that that would need to be blured in order to fulfil your suggestion.

What exactly do you mean by such a "common situation"? The only use case I can come up with tight now is when you switch to Kunagi mid-project (and have to import existing data).

Artjom Hello, I think there may be two situations such as "common situations". One is the example that your appointments, you want to import a previously resolved Kunagi stories in the project. Another example would be when the PO add stories to the backlog and maybe some lower priority stories were related to higher-priority stories and were resolved. By solving the highest priority may be of interest to the OP review backlog and closing the less important stories, like a trace, without having to consider in any sprint. Both the first case to the second, how could Kunagi treat them?

The only way to import existing project data to Kunagi would by by creating the XML files by external program or script. Kunagi has strict Scrum workflows for running a Scrum project, there is no way to to import existing, historical data via GUI.

We still do not understand your second case. Do you mean you have a hirarchical structure in your stories, like a master story and substories? We have decided not to intorduce hierarchies into stories, because this contradicts the idea of a product backlog as defined by Scrum. If you mean something else, perhaps you could post a concrete example with your stories.