My team has been working with a Kanban pull / flow system which means we have the luxury of being able to do just-in-time analysis of individual features, rather than trying to do them in a batch for an iteration. We’re getting better at this analysis, and I thought it was worth sharing what I think are some good habits we’ve developed.
Leave it until the last responsible moment
Because we move too fast to be able to write down all the details of a feature, part of the point of our analysis process is to build the shared understanding that will live in the heads of the people who’ll build the feature. The closer you do this to the time when the feature will be built, the better quality this understanding will be.
Bring the right people
Picking the people to do the analysis is important. You need a good cross-section of the people who have a vision of what they’d like the feature to be, and those with the various skills required to build it. After the meeting, these people will carry away the shared understanding of exactly what the feature is, so it’s also important that they’re likely to be the ones who will actually work on it.
Agenda
Start by talking over the feature and identifying the new scenarios that the product will need to support in order to deliver this feature. At this point it’s best not to get drawn into how hard each scenario might be to build or how much value it will add to the product – you will prioritise them later. It’s best if someone has already prepared a list of these in advance, but that list should be regarded as a catalyst for this stage of the discussion rather than a way to skip it, as the rest of the group may well identify missing scenarios or suggest innovative alternatives.
Write each scenario on a pink card with a short-hand identifier for the feature in the top-right-hand corner. Nominate a scribe in the group to do this.
Once you have your list of scenarios, get someone else in the group (other than the scribe) to read out each card in turn. Does the description make sense to everyone? Don’t be afraid to rip up cards and re-write them if the description of the scenario isn’t as clear as it could be. Now focus on the scenario in detail. Try to think of circumstances under which it might fail, noting any edge cases or success / failure criteria on the back of the card. You may find that whole new scenarios emerge at this stage. That’s fine and all part of the process – better to find out now than when you’re hacking on it.
Finally, you have a list of possible scenarios and an idea of the complexity of each one. At this point you should be able to prioritise the individual scenarios, and decide which ones are going to make it within the scope of the feature. Not everyone needs necessarily be involved in this decision, but it’s good if each of the group at least understands and has agreed to the reasons why it was made.
Sign Up
Before you leave the meeting, make sure everyone initials the green card to say they were there at the meeting. This serves to help whoever comes to build the feature so that they can easily find the experts who were there when the feature was discussed. Signing up means you understand what all the pink scenario cards mean – could you re-write them if they got lost?
Timebox
Analysis is important work, but it’s also tough and tiring. If the meeting lasts longer than an hour, take a break and come back to it later.