A team uses work items to track the progress of changes created to achieve a specific objective or task. These tasks can include enabling a user story, creating a feature, or addressing a bug. Managing releases through work items makes it easier to track the progress of the overall release and identify areas of concern.
A work item encapsulates information about an objective or task while it’s being worked on and is assigned to one individual. The work item is a historical record if questions arise about those changes. How granular you make your work items per DevOps Center project is up to you. However, if you break down your project into too many work items, it can become unwieldy and complicated to manage all the associated work items.
Work items are automatically numbered, typically in a sequential manner as they are created. However, in some cases, work item numbers aren’t consecutive. Record numbers can skip when multiple operations are running concurrently. Initially, DevOps Center uses a 6-digit auto-number format for work items, but can expand to 7 digits and beyond as required.
When a work item is reviewed and approved, you can change the status to Ready to Promote. The work item then appears in the Approved Work Items list. Now, the work item can be promoted to the first pipeline stage for testing and verification. You can have as many work items in the Approved Work Items list as you wish. However, review the guidelines regarding how many work items you can have in a pipeline stage and how many you can promote at one time. See Promote Work Items Through Your Pipeline for details.
What Can I Do to Manage My Huge Work Items List?
In a perfect world, all the changes associated with your team’s work items move through the pipeline in a timely manner. In reality, you can have numerous work items for feature work that has been postponed or changes that you never plan to move through your pipeline. But these changes hang around and stack up in the Approved Work Items list or the Available Changes list. If you haven’t yet promoted those changes to the first pipeline stage, you have options to reduce the number of pulled changes or work items in the list.
If you have multiple work items that fall into these categories, you can set the work item status to Never to make these changes available to commit in another work item. Then you can create different work items to group similar changes.
- For changes you never plan to release or move through your pipeline, create a work item to use as a “vault” for storing these changes.
- For changes with a future release date, you can create a work item to act as a “parking lot” for temporarily parking those changes. You can organize your parking lot work items by grouping all changes for a specific feature or app into a work item. When your release date approaches, you can change the parking lot work item status to Never to make the changes available to associate with one or more work items. You can break up the development work into multiple work items to assign to different team members to update, validate, and test.
You can continue to commit more changes to the work item vault or parking lot as needed.
- Open a Work Item
When you open a project for the first time, it's likely to contain several work items that your release manager created when configuring DevOps Center. You and other team members can create additional work items as the project progresses. - Modify Work Item Details
Keep work items up to date to provide full value to the team. For example, if new acceptance criteria is identified, edit the work item to ensure the assignee knows of the change. Or if you’re ready to start on an unassigned work item, assign the work item to yourself, which lets other team members know you’ve picked it up. - Work Item Lifecycle and Status
A work item includes a status and progress indicator so your team can quickly understand where work stands in the release cycle. Work items move through these statuses: New, In Progress, In Review, Ready to Promote, Promoted, and Closed. - Create a Work Item
All work begins with a work item. A work item captures a logical unit of work, such as a user story, task, or bug. Work items are organized by project and belong to the project where you created them.