I don't completely understand the issue.

If you have small Stories, assign them to a Sprint. If you have Stories too big for one Sprint, that's a process issue. You should split the Stories. If Stories are too big, the risk of wasted work (working on the Story, but producing no value at the end) is high and estimations are inacurate.

In fact, you should never have Stories with huge estimations in a Sprints. Those estimations are for lower prioritized Stories and should be split by the Product Owner as they come closer to be actually implemented and estimated seperately.

If you have long running tasks (like refactorings for example) which produce no value to the customer or product owner, you could track them as issues (bugs). Issues can be assigned to releases directly. While sprint planning you would have to take into account, that some developers are working on issues an therefore commit to fewer stories.

By longer term I didn't mean that they were long stories. What I meant was that we can't put them into the release because they may depend on other stories that can't be done until a future sprint (due to dependencies or lack of resources).
Also it always happens that a story as a task for QA to test. So what does the developer do while QA is testing the story? We have them working on another small story that we know we don't plan to put into the release.
In general we're finding it practically impossible to align sprints with releases.

I have to admit that I still cannot grasp the issue. Could you please elaborate?

Let's take your Q. A. example.

You implement a Story and give it to Q. A. for testing. Now the people that were working on the Story are free to do something else. Why don't they pick up other work from the current Sprint?

If you implement a Story that is not part of the current Sprint (leaving apart the question why exactly you would do that) and is not going to be included in the next Release, you can still include it in a later Sprint that is part of a future release that is going to include the Story.

What am I missing?

You will always come to a point where there is no other work for a developer to do in the current sprint. Testers can't test until the code is done so developers need to do more work on something else.
We have been creating a small story, that does not include testing, to keep them busy until a new sprint is started (not been easy to find such small stories however). Once the new sprint is started we create a new story to test the developers work that was completed at the end of the last sprint. This story was not tested in the last sprint so we can't put it into the release. Hence, the need to add stories to releases.

I think our problem is that we need to find work that is not a story to fill the developer gap at the end of sprints. As suggested by Witek above, maybe this can be issues but not sure we have enough non-bug and non-product owner requirement issues to do this. I would prefer that this developer idle time at the end of sprints be used to work on backlog items instead of non product owner requirements.

Its almost like we need to start a new sprint before the current one is finished.

@Nick: It seams your testers are not part of the Team (as in Scrum). Scrum suggests to include testers into the Team. This means that developers and testers have the same objectives: completing the stories they together commited to while sprint planning.

I had good experience with the following workflow:

On sprint planning you create the tasks for each story: implementation tasks, testing tasks and a bugfixing task. This enforces developers and testers to sit down together and align each others expectations. Based on the mismatch the bugfixing task gets a longer estimation.

Testers begin to test as soon as possible. On the beginning of the sprint testers have nothing to do, so they sit together with the developers (like pair programmers do). While it seams to be wasted time for testers, in fact I experienced this produces outcome very quickly. Normaly the testers get first test results after half a day.

Comming to the end of the sprint, now developers have nothing to do. So they help the testers. Here I have experienced huge improvements in test automation and error handling.

This is how I understand the Scrum Team which defines developers and testers as an entity.

Please take another look at this issue. SCRUM is supposed to manage a product backlog. Most real products have more than one version in production. If we are going to manage small features to different versions of the software in production that we need to have stories for different versions of the software in the same sprint.
This is a reality, I know you don't see this a proper SCRUM but it is what must be done and I think its important to have a tool that supports it.

Let me ask you for some details about your use case. As a developer, you want to be able to work on Stories which affect older releases, beause they are still supported?

I am trying to understand what kind of work flow makes sense for Stories here. Would it be correctly modelled, if Stories were pulled to th current Sprint, but their assosiation with the current release could be changed to another release?

Yes, that is one case. Marketing does come back ask for a intermediate release for few specific stories completed in past few sprints.

2nd scenario is, for top few stories in the product backlog, we do want to plan certain release(s).

We need to manage releases, sprints, stories and bugs. A new feature that must be added to an old version (in some cases the new feature will not be compatible with the code of a new version, so different story and code) must be tracked and managed. The options are:
1. sprint: must pull all stories into a release
2. story: Can't pull the story into a release
3. issue: If we create an issue then it must be tacked as an issue and its not part of the sprint, so it does not receive the benefits of SCRUM management.

Also, sometimes a completed sprint that has say 5 stories that we want to pull into a release must be changed because marketing decided not to include one of the features in the sprint, so we need remove it from the sprint. If we could cherry pick the stories it would be cleaner.

I just want to see if we can get the priority of this moved up and to clarify the purpose of this idea.

What we really need is to plan releases. Product marketing wants to know which release we will a specific feature. If we could plan a story much the way we can plan a issue then this would allow us to produce a PDF from the release that shows the features planned.

Today I have to manual produce a word document that list the important features that each release is planned to have. I really like the way Kunagi predicts the sprint when a story will be completed. but it is not captured anywhere. We have planned releases, so maybe Kunagi could dynamically produce a PDF report that shows which stories will be in the release if we know when the release will be (which we do).

@Nick: Thank you for posting background information for your feature request.

It seams to me, your comment kind of changes the initial idea. Instead of putting stories manually into a release, now you would like Kunagi to automaticaly put stories into releases based on the release date, using the same prediction algorithm the product backlog does? Did I understand you correctly?

Pulling stories into a release is for actual release. The automatically putting stories for a release is for planning purposes only and as such should go in the planned label much the same way issues are done and maybe should be its own Kunagi Story.