In my previous post, Starting Product Backlog Management with Azure DevOps (formerly VSTS), I gave an overview of how to create and configure your Azure DevOps project space with few tips based on my personal experience.
We ended up with a board configuration looking like this:
The board columns were defined as below:
- 0-Backlog: new story in the backlog, we don’t know enough yet
- 1-Approved: approved by the Product Owner
- 2-Ready: defined enough to be picked-up in a Sprint (as describerd in the DoR)
- 3-Forecasted: forecasted by the team in the current Sprint
- 4-In Progress: the team currently working on it!
- 5-Done: and done! (as describerd in the DoD)
While this configuration should suit well most teams, in some cases you might want to create more complex (or hybrid) flow reflecting your current ways of working more particularly for teams recently moving to an agile environment.
Hybrid Board Configuration
When starting with Kanban or an Agile transformation, it is common to start with a more traditional flow containing analysis, design or test steps, such as:
- 0-Backlog
- 1-In Analysis
- 2-Ready for Development
- 3-Forecasted
- 4-In Development
- 5-Ready for Test
- 6-In Test
- 7-Ready for Sign-off
- 8-Done
While this steps might make some coaches and trainers uneasy, let’s remember that first principle of Kanban is to start with what you do now and the second principle to agree to pursue incremental, evoluationary changes. With this continuous improvement mindset, let’s not get stuck in too many “rathole” discussions and start experiencing the flow with the aim to simplify it as we progress.
With that said, it is super easy to set Azure DevOps Kanban Board view with this workflow.
As seen in my previous post, you can add definition of done criteria for each column and also add a WIP Limit to optimise the flow. All this can be setup in the Board Column settings accessible by clicking on the “gear” button on the top-right corner.
The main consideration to have is the mapping of the Board Columns with the Workflow States. Here is how I have defined it in this example:
| Workflow State | Board Column |
|---|---|
| New | 0-Backlog |
| Approved | 1-In Analysis |
| Approved | 2-Ready for Development |
| Committed | 3-Forecasted |
| Committed | 4-In Development |
| Committed | 5-Ready for Test |
| Committed | 6-In Test |
| Committed | 7-Ready for Sign-off |
| Done | 8-Done |
Azure DevOps considers all items in Committed state as “in progress” and this drives the display of the Backlog view.
Backlog view with In Progress items display turned on:
Backlog view with In Progress items display turned off:
It is also used by the Forecasting feature when we want to forecast our future Sprints (or Release Plan) as it ignores items set to Committed or Done states as shown below:
For more about forecasting your product backlog…
Splitting Board Columns into doing and done
An alternative of creating many columns is to use the Split column into doing and done feature of Azure DevOps.
In this new example, I have updated my board as below:
- 0-Backlog
- 1-Define – split
- 2-Forecasted
- 3-Build – split
- 4-Test – split
- 5-Done
This feature feature can be quite handy, but here are the pros and cons I have gathered using it on large project environment.
Pros
- Easy to set
- Avoid having too many Board Columns
- Keep the Board relatively clean (Define, Build, Test)
Cons
- Need to use the Board Column Done field in the Backlog view to know whether an item is in doing or done
- Not convenient for tracking progress in common charts and graphs as most are based on one grouping dimension only (Board Column), such as the Cumulative Flow Diagram (CFD) or any additional charts you may add to your Dashboard to follow your progress
- You just introduced “DONE DONE” to your flow without knowing!
As usual, it always depends on your context, there is nothing wrong here, just be aware of the tradeoffs. It’s all about experimenting 😉
johonline's blog 