Grouping stories together

I love this idea too!

BUT if you want those groups to be persistent, analogous to a graphics application's layers palette, you probably wouldn't be able to start a story until it was un-groupped. Or... all the stories would need to be in the same state. ...because what would you do with a group that had one done story and the rest un-started, etc. ?

Would you still want groups even with this condition?

We would also like groups of stories, particularly as an aid to our business users who like to look at our progress at a higher level. For them, the individual stories have little meaning but the higher-level story is understandable.

From that, we have needs to show:
* how much of the group story has been done? that is, how many sub-stories have been delivered
* when is the last story of the group going to be done?
* Is everything scheduled somewhere or are parts of this group still in the icebox?

Now that I think of it, maybe the best solution is to use labels for this - particularly since different sub-stories are done in different iterations. But I don't think we can pull a report on a label and show its progress, when everything in the label is expected to be complete, etc.

I think its a great idea.

as Mark said above, there is some rudimentary grouping already in Tracker using labels. You can use that and the search panel to do most of what you are looking for:

See all stories in a group:
- use search term 'label:groupName' (or click on the label from a story)
- stories in this pane are ordered relative to each other

Stories can be re-ordered within the group.
- you can reorder stories in the search pane and they will be moved directly below their fellow story in the group*
-* currently the search pane does not show the updated order but the stories actual location has been re-ordered and if you re-run the search (just hit enter in the search field), it will show in the newly updated order

Move all stories to a new location:
- in the search pane header click 'select all' then from the actions drop down you can move it*
-* currently only to top and bottom of backlog or icebox, but this will likely improve over time

See total point value in group:
- currently I don't think the search pane shows this but it sounds useful and I could see asking the Tracker team to implement it.

How much of the group story has been done? that is, how many sub-stories have been delivered:
- The search pane is perfect for showing this information. You can tell by their order and their color how far you have gotten through a group of stories. (remember to click the 'show done stories' link to get the full list)

When is the last story of the group going to be done?:
- you can find this out by clicking the "reveal" button on the last story in the group and seeing what iteration it is in.

Is everything scheduled somewhere or are parts of this group still in the icebox?
- Again the search pane is perfect for this as the ones colored blue are still unscheduled (in Icebox)

In summary This may not be the ideal implementation of story grouping but it is pretty darn good, and as a heavy user of tracker I have use all the tricks mentioned above and find most of them to be quite intuitive once you start using them.

-Jonathan

I think a lot of agile planning techniques incorporate the idea of a "Feature" or possibly a "theme", where you can aggregate a set of related stories into a higher level of abstraction. My own experience is that while this is appealing for the product owner or other business stakeholder (ie chickens), it often just creates confusion at worst or adds little value to the implementation team (ie pigs). It also creates more overhead for the ScrumMaster or whomever is managing the backlog. The labels get us most of the way there.

However you (pivotal) could always add the feature and people like me could just choose not to use it.

My work flow tends to start with creating large Epics in my backlog. At some point (during the planning game) we break this down into finer detailed stories. Then those are broken into actual production tasks. It seems there is no real support for breaking down "epics" except for labels -- which is a bit odd. And tasks are done using 0 point chores. Seems a bit wonky. Regardless, I like what I'm seeing so far with this product!

Lack of a meaningful way to group related stories together is one of the main reasons we've stopped using this tool for our development work.

I've been grouping themes of stories together with tags and I'm totally satisfied.

I don't need or want groups any more

We are so far heeding PT's advice to not turn on tasking. With a small team, I like how that keeps us focused on the story value rather than being distracted by task management (Its not that we never think about tasks-- just that we don't want the overhead of using an online tracker to manage their ownership, estimation, and status). We can always put a note in the description or comment if we are worried we will forget a task.

However, some hierarchy would help us-- like Jason says above, for thinking beyond a one week time horizon, creating / grouping stories in epics (currently not possible in PT) has been quite helpful for us.

Groups sounds great as long as it doesn't clutter up the interface or make me jump through hoops if I don't even use them.
I think of the groups as "Epics". I use them as well but only before they are broken down into stories. Once we get to that stage the epic isn't really important unless the team needs the higher level view of what is trying to be accomplished. I think there are many ways of achieving this, so the implementation has to be carefully thought out.

PT is great for backlog management, but not being able to break stories into tasks is *the only reason* the engineers on my team (i'm a Product Manager/Product Owner) don't really engage with PT. They think it's my tool, not *our* tool. If they could log tasks under each story, we'd all be using PT daily.

Any update on this? Grouping stories (whether via Releases or not) is probably the most important feature PT is missing right now.

In the interim, something that may be easier to implement is to allow dragging of all items that are "checked" (the white boxes on the right side of each item). In terms of [your] code, everything would stay the same, except at the point of drop, iterate over all checked items in top-down order and inject them all at the drop point. Even if you guys think that is "half baked", I think it would immediately prove useful to many of us while we wait for the "fully baked" solution.

Pistos' idea is very good. It doesn't really solve the use case of "grouping stories together", but it addresses a UI weakness we have currently: if you keep a prioritised backlog, and you want to move a number of stories but keep their relative order (which you probably do most of the time), right now that's very cumbersome and error-prone.

I am trying to migrate from Redmine, and am in love with the way PT makes my sprint plan automatically, but horrified at some of the things I have to give up.

I have 5 main clients, and all of them are on another continent. They have become quite happy filing their own redmine issues (bugs and features) and leaving it to us to either develop, or bounce back to them for further clarification and discussion.

1) Some of these Redmine issues become lengthy with lots of screen shots and different points of view. Often when we are in a position to commence development I will 'Move' the issue to a tracker I created called 'Task Group' and then create all the actual tasks as seperate lightweight issues, linked to the group either as 'Related to' or 'Blocked By' depending what mood I am in.

2) An alternative technique that I have in redmine is that I can create 'Target Versions' in Redmine, assign as many tasks as I like to that Target Version, and then track them to completion as a group.

3) Lastly for smaller groups of tasks I will just create a couple of side tasks (perhaps for Admin to deploy an additional SVN repository, or the designer to provided needed artwork) and link the tasks as 'Blocks' or 'Blocked By' ect

I use all three techniques at different times and find them invaluable for keeping track of some of the larger sub-projects that come through, which can often span several months of effort in parallel with other work.

In the context of PT, and keeping it light and breezy I believe we need a simple unidirectional reference between stories: A (before) B , or B (depends on) A or however people want to use it.

a) That would allow PT to make sure that B does not/cannot be scheduled ahead of A - perhaps A will be moved ahead of B any time this is likely.

b) It would also allow a simple list of linked tasks from A (Following Stories) and from B (Preceding Stories).

c) It would be especially useful for making sure that none of the core stories needed for a release get accidentally dragged after the release that expects them (just make all core stories Before the release and the Release will be pushed later than the last story.

d) It could also be used to create story 'groups' - just make all the sub stories 'Before' the group story (which itself could be a Chore with 0 points) and it will float to the top when its last Story is done.

Separately there is still a strong need for a discussion tool to complement PT. The use case I discussed at the beginning is not well supported by PT today - even if we had linked Stories that would only solve the problem of scheduling the implementation *after* we had agreed on a way forward. But what do I do when the client (who knows little of Agile or technical issues) files a Story that represents a man month of work and we need to talk about it before we split it up?

It is all very well for you Agile teams with the client in the same room, but when they are not even on the same time zone, we support to facilitate discussion. I am not saying that it is PT's job, but our previous tool was not bad in that regard, and if the client has already populated a detailed feature request (story) it feels strange to take the discussion elsewhere and then back again?

Anyway that is a topic for another thread, my apologies. As for sub stories - absolutely vital IMHO.

We really need this as a way to manage 'epics' and implementing larger sets of features that compromise a 'critical mass' to deploy a given feature to customers. And it would especially be useful in backlog managment as it would allow PO's to see the cost for an epic or 'story group' and move it around within the backlog as a single item. The UI could be very much like how current stories can be expanded, but in this case you'd see not the details of a single story, but the stories in the container (perhaps shifted right just a tiny bit.. to visually indicate the nesting)

If I may comment more (in the hope it might bubble this item up to a higher priority in your backlog), a problem I'm dealing with at this point is my team members starting work in the wrong git (version control) branches. If we could group PT items somehow, then there would be no ambiguity as to what git branch a given task belongs to. I would specify the branch in the group description, and then it would be understood that all items in the group should be developed in that git branch. Making a label for every git branch would be too cluttered and cumbersome, in my opinion.

Lacking an ability to group tasks really reduces the usefulness of PT for large projects. It's extremely difficult to maintain a lengthy list of items in the icebox and move them to the backlog in a usable, organized fashion if things keep get buried or lost in an unorganized list.

I'd like to see expandable groups created based on the labels, where items in the Icebox are grouped automatically by label and you can expand/collapse groups in the Icebox. Also needed is the ability to order items within these groups. So if I have a group of "UI" tasks, any task that I add the UI label to should flow into that group. And even if a story is added later, yet has a higher priority than than some items added before, I should be able to easily correct the priority respective to its "peer" tasks by dragging it within the group. Currently, I haven't found a way to easily do any of this, which is leading to mass disorganization within the lists.

The fact that this discussion has been going on for over a year with no movement on this critical feature is really disappointing and is concerning from the product standpoint of PT. In fact, if I'm reading earlier comments in this thread correctly (which imply you used to be able to re-order stories within search results -- it seems you can no longer do this), it seems like the status quo has actually degraded from the previous state.

Where does this stand? Are there any plans to roll out anything?