2

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?

3 Answers 3

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.

0

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.

0

Just stumbled on this awesome question - yes, this is a core problem driven mainly by Kanban's focus on simplicity. Which is the right thing. Nonetheless, either physical or digital Kanban Board, you can opt into these options:

Physical Board

  • Use colored stickers to "tag" initiatives
  • Use pre-header labels to name initiative and then actual task/work under every card

Digital Board

  • Use tags / labels (colored preferably for quick identification)
  • Use software that allows creating sub-cards or linked cards
  • Use swimlanes as a grouping structure for related cards

There are probably few more options which I missed, but this definitely can get you going.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.