How to connect Kanban work items to larger initiatives?

Question

We are a software testing team that uses Kanban for visualizing our work. In our backlog we have both work items related to the work of testing but also the work of preparing and maintaining test systems, computers, lab etc.

Our backlog is huge at the moment and it is hard to see how work items connects to larger initiatives. Let's say we have a new feature to test. We create a test plan, a word document, and put everything in that related to the test of the feature. Then we create work items in the backlog for planning, configuring, preparing test systems, creating test cases, executing tests etc.

But it's very hard to see the connection between the work items and what part their playing in the bigger picture of the feature testing.

Are there anyway recommended ways to handle this?

Answer 1

This is a great question.

I think there are several approaches you can take, but my personal favourite is to use story mapping.

Story mapping delivers a view on the user journey (in your case, this may be the delivery of a test strategy). It helps the team to visulalise how all the individual work items connect together.

The story mapping is a living document that the team frequently refers back to and that they may also update as the work progresses.

It may even be useful for the team to view the story mapping at the start of each planning meeting, so they continually set the scene for the work they are about to do.

Answer 2

Disclaimer:

I believe there's a X>Y problem here, as you may be trying to solve the wrong problem. Maybe the underlying problem is the team structure, segregating Testing from Development, but I won't delve into this.

Back to the problem:

If you need to create a massive amount of documentation for a test, you might be covering way too much scope in a single feature. Assuming you're referring to Features as in SAFe Features, you may want to explore the possibility of creating tests at User Story level.

By reducing the unit of work, you may avoid the need to break down the test into several pieces. In this scenario, you could collaborate directly in development's user stories - no segregation needed.

Worst case scenario:

Assuming you still need to define test at feature level and that the feature is weeks / months worth of effort and that you still want isolated deliverables, then the connection between these units of work will invariably depend on the system the rest of the team is using. The solution for a team using post-its in a wall will strongly differ from the solution for a team using Trello or Jira.