在Redmine backlogs中规划项目方法前文Release,Sprint,Story和Version的关系讨论了一些基本概念。而且提到S
在Redmine backlogs中规划项目方法
前文Release,Sprint,Story和Version的关系讨论了一些基本概念。而且提到
Some terminology: when we talk abount a 'Sprint' in backlogs, we actually use a redmine 'version' - Sprints use the redmine's version.
There are some places in redmine, where the word 'version' is used - e.g. in the issue detail view.
Various ways to do the connection:
* Go to the backlogs tab and drag a story from the release (right) into a sprint (left). Then this sprint will show up in the releases page. (If there is no sprint, on the backlogs page there is a menu at the product backlog where you can create a new sprint)
* If you edit an issue, you can set a target version. This actually puts a story into the sprint. If the issue is also assigned to a release, that sprint (=version) is visible on the release page.
* On the release page, you can right-click issues and get a context menu, offering to set the Target version (=Sprint) from there.
Releases in backlogs are meant to help breaking down large backlogs into manageable terms and not required at all to do proper agile development per se. They do not enforce anything.
So if you have all your stories in the product backlog, priorize them there, and drag them directly into sprints (as you go and the project develops), you are set for continuous deployment.
The Releases on top would eventually help to communicate to non-agile customers or to get grip of a vast number of stories - or to support your requirement of planning key features.
