More on Kanban Board Configuration with Azure DevOps (VSTS)

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:

VSTS-Board-configuration

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.

VSTS-Board-configuration-2

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:

VSTS-Backlog-Display

Backlog view with In Progress items display turned off:

VSTS-Backlog-Display-2

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:

VSTS-Backlog-Display-3

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.

VSTS-Split-Column-Doing-Done

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

VSTS-Board-configuration-3

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 😉

For more about splitting columns…

Advertisements
Categories Agile, Blog, DevOpsTags , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close