Work items are way to track work progress in Azure DevOps. They tell you what the team is currently working on, what is finished and what job is still to do. That’s it. OK in real world it is not that easy, because you have different kind of work to do, tickets are moving back and forth between being closed and active etc. To tackle all this chaos, I will share a few tips that can help you get along with different problems with work items.
State
State tells you what is the current status of the work item. Different work item types can have AND usually does have different states. All the states drops into five main categories (in Agile and Scrum process models).
- Proposed – Work items that are waiting for work. Your todo.
- In Progress – Work items whose work has begun.
- Resolved – Work items that are waiting for verification.
- Closed – Done. Finito. Listo.
- Removed – Well the work item is removed. Not deleted, but removed.
No matter how many states you have defined for work items. They always drop into one of those five states. States are nice and we really like to use them to present our current state of work. We like it so much that we usually add new states like in review, waiting for testing or re-opened. However adding new state brings always more complexity in our development process. People forgets to move work items into different states, they build queries and forgets to add states into where statements, they have to interrupt their work to move work item to proper state.
I have seen in many cases that maximum number of reasonable states is seven. You may have heard of magical number of seven, but forget the +2 part. With seven state you should be able to describe almost any software process with enough of precision. For example if we think about the re-opened state, it is actually a bit problematic. When the ticket is in re-opened state, you have two different queues of work: new and re-opened. When developer starts to work with next task, should they first start with re-opened work items or the new ones. If work item is in re-opened state, it tries to say that “it is almost done, but it contains few bugs”, that can be very dangerous assumption. If work item is treated as a new, we are far more safe in our estimations of working capacity. I have one thumb rule for states and it is:
Less is more
The more states you have, the more complex your software process is. Try to minimize the amount of states and at least keep it in limit of seven.
That’s it folks. My next topic will cover the work item types and I will share some thoughts about using the features and epics to track work progress.