Card sorting is a simple and useful way to gather feedback on which features people want in a new system, which problems they want solve or generally speaking, what they want.
So I was surprised recently when some business analysts I was working with had not heard of the technique and I thought I would describe it here so they can look at it again.
All you need is something people want and a pile of cards to sort:
In this case we wanted to find whether people would like to have a BA (business analyst) on their agile project. We believe a BA on the project would be great, but nobody seems to know what they would do with a BA. In fact some people told us they are not allowed to use BAs because it is against agile law.
So instead we spoke to some people and found out what features they might look for in a BA. We came up with the following list
Next we went to visit two stakeholders and asked each to rank the top six features that they would like. The first came up with his preference and another came up with her preference:
Now we can see that some features are desirable to both stakeholders while others are liked by one person and not the other. If we speak to quite a few people we are likely to get a pretty summary of the kinds of things they like, without a long requirements document and without building anything across multiple sprints.
That’s it really.
Of course we don’t have to go and see everyone separately. We can run a workshop where people come together to vote and debate. A good way of doing this is to assign a cost to each feature and let people “spend” a fixed budget on them – such as the workshop described at the Innovation Games site – Innovations games – buy a feature.
Variations exist though ….
We could simply map out the things we want in a BA on one axis and the effort needed to find (or build or add or buy) that feature in a BA … or how hard it is to maintain once we build up a capability:
Analysing the first picture, we will find it hard to build “keeper of knowledge” but it might be worth investing some effort in it. We should definitely go for adding “prototyper” and “tester” to our skill set and should not bother with “actor” or “rapidus waterfalian”.
We could also map out what we need now and what we will need after we implement some change
According to this (not very complex) analysis – we need BA’s right now who are good at rapid waterfall requirements and being a mini-me product owner. But we should not invest too much in growing that capability because the need is diminishing. What we do need is good facilitators and detectives (now and in the future) and we do need to start building a capability in “keeper of knowledge” and testing.
So we can do quite a lot with a few cards if we want to.
You might also be interested in looking at this site that describes card sorting and adds concepts like “learning cards from Strategyzer” to capture the lessons learned from the exercise.