This project has moved and is read-only. For the latest updates, please go here.

Separate field for product/release

Mar 21, 2012 at 8:23 PM

Hello,

We were concerned with having fields that serve multiple purposes.

We have modified the standard product backlog item to include a field we call Product.  (We also renamed PBI to Story and Bug to Defect.) The Product field contains the name of the product and the release. This allows us to know which features are scheduled for the release.

We use Iteration Path exclusively for the sprints as mentioned in your "Latest Model".  We have one sprint for each two-week period throughout the year.  Allk teams are always working on the same sprint.  They may be working on different products, but the sprint is always the same.

We use Area Path exclusively for the team that is working on the story.  This will change when we go to Dev 11, since it has a Development team field.

This way each field has a single purpose.  This allows us to report for each team for a specific sprint and see which product/release they are working on.  We don't have to remember which sprints correspond with which products.

- Bruce

p.s.

Why did you choose the name "Latest" to describe the alternative model to "Declarative"?

Mar 21, 2012 at 8:42 PM

Hi Bruce,

I agree with your principle of using a field for only one purpose. We use one team project per product/funding stream, so we dont' have that problem.

The term "latest" was used because the approach is the same that we use in source control. The team is always on the latest, or most current version of the software from the root area path (i.e. root area path like the main code branch is the latest version of the SW).

In your case, consider using the iteration path field to designate assigned sprint or backlog (i.e. root) and your custom product field to indicate product and version.

Best wishes, Bob

Mar 21, 2012 at 8:45 PM

Bob,

Thanks for your feedback.  This paper is exactly what I was looking for to help us transition from an in-house test platform to MTM.

We don't want to do things the way we have always done them.  We want to make a significant step forward and I believe that this paper helps us see a way to do that.

- Bruce

Mar 21, 2012 at 8:48 PM

Thank you Bruce! :)