Task, state, column or work item?

Introduction

I see a lot of different interpretations on how to classify content in Azure DevOps. What makes something a work item? What is the difference between a state and a board column? I mean why am I even discussing states and columns in the same post as tasks and work items? Let’s dive in and look at each individually.

Work Item

The primary use for a work item is to capture something of value that needs to be delivered. If you were to describe the item to your customer and they respond with disinterest in you working on it then maybe you should consider one of the other three. I choose the work item level depending on the type of value:

• Epic: it is a waste to just call these ‘large stories’. Instead consider them as goals or capabilities you want to deliver.
• Feature: a complete chunk of value your end customer will understand. Imagine writing a user guide, these are the sections that users will search for.
• PBI: might not all be user stories but most are and since stories are small and negotiable they tend to be considered a bullet point on a feature for end users. This is especially true once you have split stories to fit in sprints.

Work Item State

I don’t think folks pay much attention to states and generally treat them as a set of steps that work goes though until its done. This gives rise to my pet hate - the testing state, the idea that you don’t do any testing until the work has cleared development.

I prefer to think of work item states in the same way as state machines:

• A work item can only exist in one state at a time (obviously).
• A state defines the set of events that can be handled and actions that can be performed.
• Events determine transitions to other states.

This is why, for cross functional scrum teams, the four states should be all that are needed:

• New: candidate ideas, not yet on the backlog.
• Approved: work items that are on the product backlog.
• Committed: work items that match the sprint goal and are on the sprint backlog.
• Done: work items that meet the done criteria and are potentially shippable.

A cross functional team will perform all sorts of tasks on a work item in a committed state - writing code, updating documentation, writing test automation, performing exploratory testing, bug fixing, merging pull requests, etc. All of these happen iteratively and often concurrently.

If your states represent the steps in a waterfall process then you are doing mini-waterfalls.

More states equals longer cycle times - I once had a customer who had 20 states from new to done and was releasing work quarterly. By the time we finished transforming their process we had 4 states and releasing weekly.

So where does it make sense to create new states? The only times I’ve needed to are for integrating into a wider, non-agile, organization at a feature or epic level. For example, if you have mandatory a hand-off of features to other teams - for example quality assurance then adding a new state at the feature level is possible.

Board Column

Board columns are a little like states but are only visible to the team that owns the board. For this reason the rules governing their use can be a little more relaxed but less is still better. An example of board columns I use regularly at feature or epic level is to rename the in progress column to now then add next and later columns. This gives a simple roadmap view of the future but its no different than using iteration paths.

Task

You have probably figured out by now that I think nearly everything that isn’t of identifiable value to the customer should be a task. Personally, I use tasks for everything. If its not written as a task I invariably forget about it. Plus the little dopamine hit you get from ticking a task off feels great throughout the day.

Testing…task; writing documentation…task; reviewing a PR…task; updating a build script…task; if in doubt…make it a task.

The one time this sometimes isn’t so simple is for bugs. If you find a bug in a PBI before its done is it really a bug? I wish Azure DevOps would allow you to create bug-tasks like JIRA that work like tasks but visually appear as bugs. Until then I prefer to create another task but style the card on the task board. Bug work items are reserved for defects found after the PBI has been completed and the sprint ended. This differentiation also helps calculate the escaped defect ratio for sprints.

To aid with all these tasks there is a fabulous extension called 1-Click Child-Links but sadly I don’t think its been maintained and there are now plenty of issues. Alternatively using the az boards work-item command line can alleviate some of the grunt work.

Finally

Hopefully the above provides a little bit of guidance on the use of various Azure Board features. What I haven’t talked about are tags which are incredibly useful when it comes to removing columns and states. More on this in a later post.

Photo by James Snape on Flickr