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:
- New: someone just threw it in the backlog. Needs lots of definition.
- 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.
- Estimated: the team has provided an estimate good enough to start work.
- Ready: the customer approves of the scope and estimate, and can be started on at the team's convenience.
- Active: the team is actively developing or testing an item.
- QA Complete: the QA team verified to the best of their ability that the work items meet the acceptance criteria.
- In User Acceptance Testing: a customer can start using this new thing.
- Approved for Release: the customer wants to proceed with a production deployment.
- 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 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:
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.
- 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 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.