Loading Profile...
Twitter,
Facebook, or email.
Managing multiple project work items within a single team project
Our team works on multiple projects within our product backlog. We use one TFS project to track all project work items, their features and stories. We plan stories by iteration but not features or project items. Ideally, I'd like to see the project and feature work items with the stories for planning without having to actually mark the entire feature or project for an iteration. Any ideas how to do that? I can't add these work items into the configuration template as that seems to force me to mark the entire project for a single iteration. Thanks.
-
I'd like to hear from others regarding this question. Urban Turtle filters work items according to their iteration and area, making it just about impossible to show the Feature work item you are mentioning without assigning them to a specific iteration/area..Comment
-
-
One simple solution might be to set a prefix for every user story with the project name in the title. So the title will be [projectname] - [user story title]. That is how we use it now.
Another option can be to add a custom project field in the TFS template you are using, but then another turtle wish arises; the posibility to show custom fields in the planning board ;)
Hope this helps you going on-
Well technically, you can show custom fields on the planning board, although you cannot display any number of fields. We're increasing this limit to three Urban Turtle 3.11, but the Title is still considered a custom field and is pretty much required. But with the next version, you'll be able to display both the Effort and Business Value fields for the Scrum 1.0 Product Backlog Item work item type.
-
-
-
-
-
We have a similar need.
Here is our scenario:
- one Team Project, many products. We use Iterations, Areas and the Team feature to filter them
- within a single Product we have sub-areas
- within a single Product we have different features\mini-projects which could span multiple sub-areas and obviously multiple iterations
- each feature is made of stories
Few years back we added a custom field to the work items. That custom field is our way of grouping stories in features, give priority at feature level, see in each iteration which feature is being worked on, etc.
Now, because that's a custom field we cannot really leverage it in UT. So, we were looking at story hierarchy to achieve the same, but that's not the way. One reason is that the root story (representing the feature\mini-project) should always be visible in the planning board for each iteration as long as one of its child story is part of that iteration. And that's not the case.
I have a pretty clear view of what I'd like in the planning board related to this :)
Let me know if you're interested in more details. -
-
I believe what you are referring to as feature/mini-project stories is akin to the concept of Epic Stories. Our Scrum coaches would recommend that these be broken down into smaller stories which could be completed during a single iteration. Furthermore, once the Epic Story has been decomposed in regular stories, it should then be removed from the backlog. You could keep a "related-to" link between the epic and the stories, but this link would not be visible in Urban Turtle. But you would at least still have access to the epic story should you need to refer to it (which you shouldn't, as your stories should be self-contained).
-
-
>>You could keep a "related-to" link between the epic and the stories, but this link would not be visible in Urban Turtle
That visibility is the critical bit for us. That's why we initially added a custom field (it's a sort of tagging). -
-
How would you like to see this made visible in Urban Turtle. For technical reasons, a work item can only be displayed once. We could maybe add an icon on the work item when it is related to others. Clicking on this icon could display a list of related items. Did you have something else in mind?
-
-
I was thinking about something like a sort of grouping.
We're trying to use the project WI. It's fine in the backlog (as a grouping mechanism), but then we dont see it (as expected) in the single iterations.
I guess that grouping by a given field (even a custom one) might be ok. Then no matter where you are you can group and have a "higher level" view. From there you could think of showing number of items and story points per group (but that's probably not so important). -
EMPLOYEE
