Products workflow

Create and organize a product hierarchy that makes sense for your product. As the team works on the product release, they can use many parts of the tool to help them find, update, and deliver supporting artifacts quickly.

A team administrator can change the term product to a term accepted in your organization in Administration > Settings > Rename Products. An administrator can rename the product term at any time.

After the term is changed and saved, the custom term is used in menus, dialog boxes, and messages. Users running sessions must refresh their browsers to see the custom terms changes. The product term will continue to display in the hover help and the product documentation.

The following workflow is typical for a team at work on a product release.

  1. Creating a product configuration

    The top of a product tree must be a product configuration. This is because configurations determine the versions of all the products in a configuration. (Products know their immediate child products, but not the versions of those child products.)

    Anyone can create a product hierarchy in the Browse Products page, but typically the team lead or product manager organizes your product. Products can be organized by release, model year, product model, season, customer age groups, or any other category that makes sense for the product.

  2. Create products to support your product.

    For steps, see Creating a product and Importing files from other tools as baselines.

    Products can use dimension and value pairs to express variations in your products based on those dimensions and values. A dimension describes how a product or product branch is unique by defining its aspects. A dimension consists of a name, such as geo, and a value, such as uk. For example, if your product is a speedometer created in the United States, you could create a variant of the speedometer product for the United Kingdom.

    When you set dimension and value pairs for a product or product branch, the pairs determine whether or not the parent configuration gathers it as a child product. Each dimension and value pair must be unique, but you can add as many pairs as you need to products.

    Read about the behavior of dimensions in the Create Product dialog box, in Dimensions hover help.

  3. Add links to products.

    A product hierarchy alone is not useful. The products must contain the information to build the product release, such as requirements, design models, work items, and test cases.

    For steps, see Linking to work items, requirements, and more.

  4. Perform iterative work on the product hierarchy.

    After the product hierarchy is built and links to artifacts are in the products, the team begins the iterative work to reach a milestone. More work items are created to drive design or requirements changes, which in turn drive rework to test cases. Team leads will need to query for artifacts to build progress reports. Team members will want views to see the product lifecycle visually.

    During this time, some of the work to be completed includes creating and populating folders. Folders contain product-specific views or queries or reports to focus the work that teams need to complete. For steps, see Creating folders to organize queries, views, and reports.

    As work continues, teams might need to reorganize the product structure. Reorganization is necessary if teams need to rename, move, reuse, or remove products. For steps, see Manipulating product configurations and products.

  5. Capture a milestone.

    At a certain point, your team reaches a milestone, such as a sprint date or beta release. Milestones are good places in the product release to create a baseline of a product configuration. For steps, see Creating a baseline to capture a milestone.

  6. Check out branches to support variant products.

    Sometimes even more changes occur to the product, requiring new variants to be added, which are called branches. A branch is usually a child product, such as a paper tray child product in a printer product. For steps, see Creating a variation to branch a product. When a branch is checked out, a child product might need to be moved or reused for the new branch. For steps, see Manipulating product configurations and products.

  7. Solve a problem with a product.

    At some point in a product release, product development might stop because of a problem. You might want to compare versions to see where a problem was introduced, find where a problematic child product is used, and view the history of changes. For steps, see Comparing product configurations, Finding where a product configuration or product is used, and Viewing audit history.


Feedback