Separate sprint objects from version

[patrickatamaniuk]

platform: # supported: 2.0.4, 2.1.6, 2.2.3 backlogs: # supported: 0.9.36 ruby: # supported: 1.9.3, 1.8.7

see Roadmap

[patrickatamaniuk]

Thoughts on migration: 1 check all existing versions which are targeted by issues with story/task_tracker 2 then create sprints and move over the stories 3 then retain versions still containing issues 4 remove empty versions if they have been emptied in step 2

Thoughts on implementation: see also http://www.redmine.org/issues/13387 Sprints and Releases are the same concept. a abstract RbRelease object and use for both b or abstract Version object and re-use code emerging from above mentioned redmine ticket. ?Uhm... - that might be hard to maintain c do a) and when abstract versions are available in redmine think again.

To get started it might be best not to use ActiveRecord single table inheritance and polymorphic relations - these are not the best database design, and the gain is minimal. Most probably views/controllers/filters/patches need to be duplicated in any case. Any pro STI arguments?

Features of a Sprint (or Release)

• history - i want to see when something has been changed, who has added, who repriorized it
• locked sprint - lock down adding issues or changing estimates?
• roadmap integration
• initial capacity to aid planning sessions
• a sprint goal text field, prominently visible
• sharing across project

This is not exhaustive - discussion is welcome.

[Cissi]

@patrick Today we finally found the time to test and upgrade our current production database. I have been looking around and I can say that we are on the right way, but still needs some more work. Thanks for the tremendous work you and bohansen have done. I do have some first initial comments as usually.

Some background information, in our major project that I am PM for we had a huge backlog that was split into different sprints, currently I have 8 planned sprints spanning from now until beginning of august in the left column and I have identified 4 releases during the same period of time. That means I have a lot of information in the backlog view and the three most closest sprints have stories planned into them and the longer down the list the sprints are still empty and the stories still are in the backlog or a specific release backlog.

In your implementation you have all the releases in the right hand side, once you create a sprint you move the story from the planned release backlog into different sprints. Making that specific release backlog empty. I saw that you could choose which releases you want to show in the backlogs view and that is very good, but I would prefer that once you have emptied a release backlog of stories into different sprint you should make a wrapper around the sprints that are included in that release to make the actual release still visible not removing them from the view. For instance if sprint x and y are included in release A, The release A wrapper appear around those two sprints when the release A backlog are empty.

Then you still see the timeline and connection of the actual sprint and the longer release plan at a glance and you also get a sense of when things might be released.

Or you have sprints and releases in the left column and only have one backlog as before. In that way you move a story from the backlog into a sprint and a release at the same time, and the longer down the list the less defined the sprints/releases are. If you have a very fixed project you might not have anything in the right hand side except for change requests and bugs etc. that are not planned work from the beginning and are more of ad- hoc nature.

I also like the idea of epics in a release backlogs, since in the planning phase you might not really exactly know which stories you will have to solve a epic. That is the closer the actual implementation of a release the more stories are added, making the actual goal of the epic happen. But I thought that the epic planning was supposed to be a separate page. Don't remember where this discussion took place, the forum probably...

The rest in your issue, I still need to think a little about and get back to you.

I last comment I do believe that deliverables are planned to a certain milestone or a specific date. You cannot simply have only deliverables without stating when they are due and you tend to group deliverables into one date instead of many small milestones since you simply need to group things to get an good overview as a PM and you also need to have different periods of activities in a project to be successful unless you have continues releases. For the same purpose you need epics to be able to group a large backlog into something that is easy to grasp and communicate to people outside the actual team. I mean the team-members can(maybe) have a good overview but for persons outside the project to understand what will happen reading only the stories will not be easy from time to time. Might be we are bad in writing good story headings but you tend to have a initial working name that not make sense for people outside the project that will pay for the actual development, then it is good to be able to have the epic approach to explain what a group of stories is trying to achieve, the deliverable. And the epics will be shown in the release not all stories and tasks...

OK, that is all for now. I might come back after testing and thinking more about this.

Keep up the good work, saw that you have finally added the graph, now I need to update again on Monday... :-)

Best Regards Cecilia Dahlgren

[patrickatamaniuk]

@Cissi Good thoughts. Offtopic: Epics: same usecase at my place - overview and communication. Discussions have not taken place, i threw it into the forum but i'm quite lonly in that thread.

Graph: not yet in, it is still a featurebranch here.

Releases: yes, it is confusing that the releases are become 'empty', while actually the stories still belong to them. Framing sprints with the release would clarify that, but would require that a sprint has to be completely in a release, then. Currently, a sprint can contain stories from a release, and from another or even release-free stories. My place uses this freedom. Maybe it would make sense to leave a 'shadow' of a story in the release container, while displaying the real story in the sprint.

We should split these ideas into a Release-usability issue, as this ticket here was intended to require the separation of sprint and redmine-version, while keeping the system behavior.

[Cissi]

@patrickatamaniuk sorry if I messed up the issue, I should have put my thoughts in the forum instead. Just split and move it as you want. BR Cecilia

[patrickatamaniuk]

@Cissi no harm done, your thoughts are very welcome here.

[Cissi]

@patrickatamaniuk I created a new issue #882 where we can continue the discussion.

[meezaan]

This will probably go away when sprints and versions become separate, but for now we need to specifically set a start date on the backlogs screen for a version / sprint (because we can't set a start date under Settings > Versions.

If the start date is not set, we have no burndown charts (that makes sense) and you get an error when trying to create a multi release view and deleting a release if the release has tasks that also appear on a sprint without a start date.

This may have been flagged elsewhere too, but just thought I'd mention it here as separating sprints and versions will probably solve this problem altogether.

[jekkel]

Sorry for my late participation but I would propose backlogs using redine versions for modelling releases and using a separate object type for sprints. This would integrate nicely with other (reporting/roadmap/...) plugins and in my understanding releases are more like redmine versions than sprints are, namely because the project artifacts should be in a releasable state with a fixed version number as soon as the "release" is finished.

I understand that switching everything around won't be easy, but in the end this also solves #864 for free (with sprints being excluded from the roadmap, which is at least one thing my company would benefit from).

On the other hand, redmine issue 13387 and the generic target type resulting from that would solve a bunch of backlogs issue. Unfortunately it seems no active development is done on that issue.