A team administrator can change the term product to a term accepted in your organization in . 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 information center help.
The following workflow is typical for a team at work on a new product release.
Anyone can create a product hierarchy in the Browse Products page, but typically the team lead or product manager organizes the 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.
For steps, see Creating a product.
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.
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 products.
Use product groupings to collect like products into meaningful groups for you or your team. After you have created a product grouping, you and your team can view it in the products list box. For steps, see Creating a product grouping
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 frozen versions of a product hierarchy. For steps, see Checking in a version to capture a milestone. After you have checked in the product hierarchy, any change to a product creates a new modifiable version. Alternatively, if you specifically chose to freeze the product hierarchy, then it is non-modifiable. Perform an unfreeze operation to make the product hierarchy modifiable again.
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 products.
As the work on your product progresses and you achieve the next milestone, check in a version at each critical juncture to save the product hierarchy.
At some point in a product release, some aspect of product development might cease 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 products, Finding where else a product is used, and Viewing audit history.
When your product is ready to be released for general availability, check in and freeze the final product hierarchy.