search

backlogs / redmine_backlogs

A Redmine plugin for agile teams
https://backlogs.github.io/www/
GNU General Public License v2.0
773 stars 460 forks source link

Feature request: Release-usability better visability of releases in the backlogs tab. #882

Open Cissi opened 11 years ago

Cissi commented 11 years ago

platform: 2.2.X or 2.3.X # supported: 2.0.4, 2.1.6, 2.2.3 backlogs: any upcoming release # supported: 0.9.36 ruby: ? # supported: 1.9.3, 1.8.7

Patrick said " 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."

Cissi commented 11 years ago

@patrickatamaniuk It do not need to mean that all stories in a sprint should be in a release, Usually you split big things that needs to be developed over many sprints into several stories (epics), that means that epic A needs to do story 1, 2 and 3 and story 1 and the stories needs to be spread over the same time period, you could allow stories to have set a different release number even though you develop it during the period of another sprint. You have several other stories in a sprint that are not actually part of the release like bug report handling, support issues etc those might not have a release connected to it. You also have the administrative stories like sprint planning, sprint reviews etc those stories might not be a part of a release but they are part of a sprint. But still they occur during the time period over a release.

Do you see what I mean, you do not need to bind all stories that are framed in release to belong to the sprint, as long as the actual sprints occurring during a sprint are framed of a release.

Does it make sense? I really would like that behaviour.

@Inger & @bohansen if you are reading this, what are your thoughts on this?

I mean you would gain a very good overview of how the sprints overlapping or not overlapping different sprint, I mean if a sprint extend over two releases you can show the same sprint in both releases on the left hand side, then you easily can show what stories in the sprint needs to be solved before the release is and still keep the sprint together. If a story belongs to a different release we could either differ in colour or just be happy that it is visible when you see the tool tip of the story.

I will try to make a picture later to make an example of what I would like.

bohansen commented 11 years ago

I like the idea of shadowing or otherwise tagging the stories in the release which has moved into a sprint. A checkbox in the filter dropdown to show/hide the shadowed stories would be nice too.

I agree with your description. A sprint can always contain stories from whatever release (or product backlog) the user wants.

How would drag/drop positioning work if stories are to be shown both in release and sprint at the same time? Should stories assigned to sprint always go in the top of the release?

bohansen commented 11 years ago

I think I need to see that image to understand the last part. I'm not sure how it would work to box the sprints into release container on the left side. As I understood the shadowing it was only for the release container to the right?

patrickatamaniuk commented 11 years ago

@bohansen shadowing would be only in the release container - as an alternative to framing the sprints. DnD would simply be disabled on them, they could be greyed out and have a text or tooltip indicating what happens. Positioning is a problem indeed, stories loose their 'in-release-position' when positioned within a sprint. Displaying them at top would seem understandable.

@Cissi Displaying a sprint twice is problematic, i'd be confused as a user. All your usecases where stories are or are not in a release and mixed in sprints i do see.

The aspect of this request 'make it visible, what story is in which release' is also important for me when i am interpreting the release-graph (to come) and wondering why it behaves not as expected. Having a good visibility of releases on the backlogs page will prevent me from having stories in the wrong release by drag-drop accidents.

Cissi commented 11 years ago

Releases framing sprints in backlog tab

See picture on how I imagine the framing of sprints.

In the left column it is strictly date based, if a sprint fit 100% into the dates of the release the sprint is part of a release. Stories in the actual sprint can belong to a later release that is only shown when hoover the story.

@patrickatamaniuk I changed my mind you will not be able to display the same sprint twice. I agree the main focus is to get a good overview not to make it complicated. So a sprint can only belong to one Release or none. Even though you might use the first week in the sprint outside the release frame no new features are added into the release so that is not a problem.

Show or not show the release backlogs you decide as current configuration. The colours are not meant to be there I just did it since I do not have the backlogs GUI in excel. The only information I want is the start and end dates of the releases and preferable you can change both sprint dates as today and release date to either move a sprint into a release or move a sprint into a release. But it must be very clear what dates you are changing the release dates or the sprint dates.

When drag and drop of story from right side you only set sprint value, setting release value you do when moving story from backlogs to a certain release backlog. Or you do it manually when you edit a story.

Does it make sense!! We still keep the flexibility of having stories that belongs to different releases in a sprint but you see which sprints belong to which release at a glance, so if we are about to move a story from one sprint to next might also affect what you will be able to release and that is very obvious then, in that case you manually need to change the release value. Today that is almost impossible to see easy in the GUI.

Comments? Questions? I do not know how to implement it though :-)

bohansen commented 11 years ago

Thanks for the explanation, an image clarifies a lot :). As I understand it you propose a strict relationship between releases and sprints - yet it should still be possible to add a story to a sprint coming from a different release. I think this contradicts each other to do that. I'd rather keep the sprints completely decoupled from the releases. One might for example work on two releases in parallel, but still organize the team's committed work in a single sprint. The tooltip shows which release a story belongs to, but if we could find space for tags it could be used to show which release a story belongs to when positioned in a sprint.

The release page (when the graph part is finished at least) should help to give the overview about the progress of individual releases.

I understand your concern in the last part regarding putting stories into a sprint which is after end date of release. Maybe we could highlight stories falling into this category when they are dragged to a too late sprint? If you want the highlighting to go away you have to manually adjust the release of the given story.

jekkel commented 11 years ago

I like this last suggestion, showing tags on stories marking them as being part of a release. I wanna suggest a more detailed version, though.

See this simple mock: backlog-marked-releases

I think this solution has the following benefits:

What do ya think?