<p>There is no single, perfect solution that I've found. The default work item statuses are pretty sparse, and ill-defined, but they are meant to be super generic to apply in the maximum number of use cases. Yes, people say you shouldn't add statuses. I think those people are wrong, and partially right.</p>
<p>Each work item broadly goes through these phases:</p>
<ol>
<li>New: someone just threw it in the backlog. Needs lots of definition.</li>
<li>Design/Analysis: business and technical requirements get hashed out. Bugs get investigated. Mockups get created. Scrum teams are doing backlog grooming sessions for these items. Clients need to approve stuff.</li>
<li>Estimated: the team has provided an estimate good enough to start work.</li>
<li>Ready: the customer approves of the scope and estimate, and can be started on at the team's convenience.</li>
<li>Active: the team is actively developing or testing an item.</li>
<li>QA Complete: the QA team verified to the best of their ability that the work items meet the acceptance criteria.</li>
<li>In User Acceptance Testing: a customer can start using this new thing.</li>
<li>Approved for Release: the customer wants to proceed with a production deployment.</li>
<li>Released: the team deployed and the customer ensured it made it out.</li>
</ol>
<p>Work item states are great for many of these points in the lifecycle, whether doing agile, scrum, kanban, or waterfall. Feel free to name them appropriately for your team's workflow. I have found the Design/Analysis phase has a lot of nuance that isn't easily captured in the &quot;state&quot; of an item.</p>
<p>Client approvals seems to be a missing &quot;thing&quot; in Azure DevOps. Rational Team Concert by IBM has an Approvals feature for their work items, which is nice. For Azure DevOps, configure the <a href="https://learn.microsoft.com/en-us/azure/devops/boards/boards/kanban-basics" rel="nofollow noreferrer">Kanban board</a> for your backlog to add columns for these approvals. Azure DevOps tracks these column assignments in the work item history, so provide meaningful names and descriptions for these columns.</p>
<p>Many times, columns will map directly to work item states. Other times, it won't. This is similar to how I set up our Kanban board. The table header shows the Kanban column names, and underneath shows a corresponding work item state:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th><strong>New</strong></th>
<th><strong>Design/Analysis</strong></th>
<th><strong>Example Mapping</strong></th>
<th><strong>Backlog Grooming</strong></th>
<th><strong>Estimated</strong></th>
<th><strong>Ready</strong></th>
<th><strong>Active</strong></th>
<th><strong>QA Complete</strong></th>
<th><strong>UAT</strong></th>
<th><strong>UAT Complete</strong></th>
<th><strong>Done</strong></th>
</tr>
</thead>
<tbody>
<tr>
<td>New</td>
<td>Design/Analysis</td>
<td>Design/Analysis</td>
<td>Design/Analysis</td>
<td>Estimated</td>
<td>Ready</td>
<td>Active</td>
<td>QA Complete</td>
<td>UAT</td>
<td>UAT</td>
<td>Done</td>
</tr>
</tbody>
</table>
</div>
<p>The Design/Analysis part has a number of columns to represent that back-and-forth process of defining and refining requirements. Finally, the user acceptance testing side of things needed a little more explicit naming, but from a process perspective we didn't need a separate status. This was arbitrary, and simply worked for us.</p>
<p>When things like mock ups, UML diagrams, or other design documents must be produced, consider adding Task work items under the relevant story to encompass this work.</p>
<p>If work item states, Kanban board columns, and Task work items are not sufficient to capture the nuance of your process, you can always resort to tagging work items and creating work item queries.</p>
<p>To summarize:</p>
<ul>
<li>Add work item states to capture the main points of your lifecycle.
<ul>
<li>Litmus test: switch to the backlog view, highlight items, right-click, copy to clipboard. Paste into a spreadsheet. If the work item states are not sufficient to communicate where the item is in your process <strong>to management</strong> then add a work item state. Ignore people who recommend using a Kanban board for this.</li>
</ul>
</li>
<li><a href="https://learn.microsoft.com/en-us/azure/devops/boards/boards/kanban-basics" rel="nofollow noreferrer">Configure a Kanban board for your backlog</a> to add columns beyond what work item states can communicate. This can work well for customer approvals, as long as they are they ones to change the column.</li>
<li>Use Task work items when doing things like mock ups and other design documentation.</li>
<li>Any other non-standard or wonky edge cases can be captured by tagging work items and developing <a href="https://learn.microsoft.com/en-us/azure/devops/boards/queries/using-queries" rel="nofollow noreferrer">work item queries</a>.</li>
</ul>

CC BY-SA 4.0
2022-10-07T12:09:11.203Z
2022-10-07T12:09:11.203Z
Greg Burghardt
<p>I'm working as a product owner in a software house. For the project I'm taking care of, we're using Azure DevOps to manage our backlog. The team consists of 3 developers + me as product owner / part time developer.</p>
<p>By default, Azure DevOps offers the following status values for Bugs and Product Backlog Items:</p>
<ul>
<li>New</li>
<li>Approved</li>
<li>Committed</li>
<li>Done</li>
</ul>
<p>For me as product owner it turns out that these status values are not enough to keep the overview over the entire lifecycle of the bugs / product backlog items, because I'm missing an overview of features / backlog items / bugs</p>
<ul>
<li>whose quote must still be approved from the customer</li>
<li>that have been released to the integration environment, but must still be approved</li>
<li>that have been approved</li>
<li>that have been released to the production environment.</li>
</ul>
<p>Long story short, the status values in Azure DevOps are covering only a part of the lifecycle of the backlog items.</p>
<p>To have more overview, I'd need additional values, like</p>
<p><strong>Statuses before the development starts</strong></p>
<ul>
<li>Customer requires a feature</li>
<li>We sent the quote for the feature to the customer</li>
<li>Customer approved the quote</li>
</ul>
<p><strong>Statuses after the development done</strong></p>
<ul>
<li>Feature / bugfix is released to the integreation environment</li>
<li>Customer approved the feature / bugfix</li>
<li>Feature / bugfix is released to the integreation environment</li>
</ul>
<p>I've read about several possibilitites to achieve this, e.g.</p>
<ul>
<li>Introducing additional status values (some people dissuaded me from this option)</li>
<li>Working with Tags</li>
<li>Working with Area paths</li>
<li>Working with Custom Fields</li>
</ul>
<p>I strongly assume that I'm not the only one who's facing this issue.
What would you recommend considering your experience so far?</p>

<azure-devops>
How to keep the overview over the entire lifecycle of backlog items
Dario
# How to keep the overview over the entire lifecycle of backlog items

(Asked by: username_0 on 2022-10-03)

I'm working as a product owner in a software house. For the project I'm taking care of, we're using Azure DevOps to manage our backlog. The team consists of 3 developers + me as product owner / part time developer.

By default, Azure DevOps offers the following status values for Bugs and Product Backlog Items:

* New
* Approved
* Committed
* Done

For me as product owner it turns out that these status values are not enough to keep the overview over the entire lifecycle of the bugs / product backlog items, because I'm missing an overview of features / backlog items / bugs

* whose quote must still be approved from the customer
* that have been released to the integration environment, but must still be approved
* that have been approved
* that have been released to the production environment.

Long story short, the status values in Azure DevOps are covering only a part of the lifecycle of the backlog items.

To have more overview, I'd need additional values, like

**Statuses before the development starts**

* Customer requires a feature
* We sent the quote for the feature to the customer
* Customer approved the quote

**Statuses after the development done**

* Feature / bugfix is released to the integreation environment
* Customer approved the feature / bugfix
* Feature / bugfix is released to the integreation environment

I've read about several possibilitites to achieve this, e.g.

* Introducing additional status values (some people dissuaded me from this option)
* Working with Tags
* Working with Area paths
* Working with Custom Fields

I strongly assume that I'm not the only one who's facing this issue.
What would you recommend considering your experience so far?

**Tags:** azure-devops


---

## 1 answers

### Answer by username_1 on 2022-10-07. Score: 0

There is no single, perfect solution that I've found. The default work item statuses are pretty sparse, and ill-defined, but they are meant to be super generic to apply in the maximum number of use cases. Yes, people say you shouldn't add statuses. I think those people are wrong, and partially right.

Each work item broadly goes through these phases:

1. New: someone just threw it in the backlog. Needs lots of definition.
2. Design/Analysis: business and technical requirements get hashed out. Bugs get investigated. Mockups get created. Scrum teams are doing backlog grooming sessions for these items. Clients need to approve stuff.
3. Estimated: the team has provided an estimate good enough to start work.
4. Ready: the customer approves of the scope and estimate, and can be started on at the team's convenience.
5. Active: the team is actively developing or testing an item.
6. QA Complete: the QA team verified to the best of their ability that the work items meet the acceptance criteria.
7. In User Acceptance Testing: a customer can start using this new thing.
8. Approved for Release: the customer wants to proceed with a production deployment.
9. Released: the team deployed and the customer ensured it made it out.

Work item states are great for many of these points in the lifecycle, whether doing agile, scrum, kanban, or waterfall. Feel free to name them appropriately for your team's workflow. I have found the Design/Analysis phase has a lot of nuance that isn't easily captured in the "state" of an item.

Client approvals seems to be a missing "thing" in Azure DevOps. Rational Team Concert by IBM has an Approvals feature for their work items, which is nice. For Azure DevOps, configure the [Kanban board](https://learn.microsoft.com/en-us/azure/devops/boards/boards/kanban-basics) for your backlog to add columns for these approvals. Azure DevOps tracks these column assignments in the work item history, so provide meaningful names and descriptions for these columns.

Many times, columns will map directly to work item states. Other times, it won't. This is similar to how I set up our Kanban board. The table header shows the Kanban column names, and underneath shows a corresponding work item state:

| **New** | **Design/Analysis** | **Example Mapping** | **Backlog Grooming** | **Estimated** | **Ready** | **Active** | **QA Complete** | **UAT** | **UAT Complete** | **Done** |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| New | Design/Analysis | Design/Analysis | Design/Analysis | Estimated | Ready | Active | QA Complete | UAT | UAT | Done |

The Design/Analysis part has a number of columns to represent that back-and-forth process of defining and refining requirements. Finally, the user acceptance testing side of things needed a little more explicit naming, but from a process perspective we didn't need a separate status. This was arbitrary, and simply worked for us.

When things like mock ups, UML diagrams, or other design documents must be produced, consider adding Task work items under the relevant story to encompass this work.

If work item states, Kanban board columns, and Task work items are not sufficient to capture the nuance of your process, you can always resort to tagging work items and creating work item queries.

To summarize:

* Add work item states to capture the main points of your lifecycle.
  + Litmus test: switch to the backlog view, highlight items, right-click, copy to clipboard. Paste into a spreadsheet. If the work item states are not sufficient to communicate where the item is in your process **to management** then add a work item state. Ignore people who recommend using a Kanban board for this.
* [Configure a Kanban board for your backlog](https://learn.microsoft.com/en-us/azure/devops/boards/boards/kanban-basics) to add columns beyond what work item states can communicate. This can work well for customer approvals, as long as they are they ones to change the column.
* Use Task work items when doing things like mock ups and other design documentation.
* Any other non-standard or wonky edge cases can be captured by tagging work items and developing [work item queries](https://learn.microsoft.com/en-us/azure/devops/boards/queries/using-queries).


---

