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?

I abuse Release markers for grouping. All stories above the release marker is considered a part of a group. Unfortunately, there isn't a way to mass-move them except for Move to Top/Bottom of Backlog.

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.

Labels = grouping imo.

I think we need sub-tasks, though. If I have a story that requires UI and service layer work, I have to break it up into two parts- one for my UI developer and one for my service developer. This gets confusing to my users who see two very similar stories for the same piece of functionality. It's also difficult to show stories that have dependencies on each other (I know this breaks an Agile principle but whatever).

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.