(1) Pick a new feature to add to the product you’re working on.

(2) Sit down with the customer (or their representative on your team) and brainstorm all the scenarios that might happen when a user tries to use the new feature. Try to make the scenarios as small and granular as you can, so that you can prioritise them independently, but make sure that each one constitutes some tangible difference to the user’s experience of the product.

(3) Prioritise the scenarios in terms of

• the value they’ll give to the customer if you can make them actually work for real
• how easy they’ll be to build
• how likely they are to actually happen in real life

(4) Take the highest priority scenario, sit down with your customer (or their representative on your team) and write an automated test that simulates the scenario. The canonical way to express the scenario is using the Given… When… Then… structure to

• put the application into a certain state
• do something to it
• then check that it has ended up in the state you expect.

Use your favourite test automation tool - it doesn’t have to be fancy. At this stage, it doesn’t have to pass, either. In fact it would be quite weird if it did. Make sure that the customer stays engaged and can understand the test that you’ve written. Make sure you both agree that the test you’ve written seems to be an accurate reflection of the scenario you discussed in step 2. We’ll call this your acceptance test.

(5) Say good-bye to the customer (or their representative on your team) and find a programmer to pair with - you have some code to write.

(6) Working from the outside-in with your pair, first make sure that the automated acceptance test you wrote in step 4 can actually drive the application. This can be awkward at first, but once you get the hang of it you’ll build up a battery of hooks that can make your application sing and dance with a few lines of code. It’s an investment worth making.

(7) Now it’s time to change the code in the product to make this scenario come to life. Run your acceptance test to find out what to do next: Are you trying to click a button that isn’t there? Then add one! Work your way in from the outer-most layer (the failing test) into the user-interface and then down into the main body of the code.

(8) As you follow the sign-posts given by your failing acceptance test, you may find you run into a couple of problems:

• You get bored waiting for the acceptance test to run, because it’s slow driving the whole application stack
• You can’t easily pinpoint the cause when the acceptance test fails.
• You discover some subtle variations or edge cases in the scenario that would not interest the customer, or will be hard to write an acceptance test for, but will need to be dealt with to make the product robust.

Listen to your boredom: Now it’s time to drop down and write a unit test. Or should I say microtest?

(9) When your unit test have gone from red to green, and you and your pair are satisfied with your refactoring, run the acceptance test again and get your next clue.

(10) Repeat from step (8) until the acceptance test passes.

This post was heavily inspired by a talk I saw some time ago from Dan North and Joe Walnes, and by all the fun I have hacking on Songkick.com

• There are no iterations: only now. Work at a pace you can truly sustain.
• Done means it is in the user’s hands. Nothing less.
• Limit the Work in Progress. This forces you to get things done, or you’ll have nothing else to do.
• Get better all the time. Keep tuning your process and tools to fit the way you need to work today - make kaizen a culture, not an event. Everyone is responsible.
• Decide with data. Collect the data you need in time to make responsible decisions.

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.

Estimate: an approximate calculation of quantity or degree or worth

Commitment: the act of binding yourself (intellectually or emotionally) to a course of action

• Estimates are not commitments.
• Plans based only on estimates are bad plans.
• Commitments based only on estimates are at best foolish, at worst dishonest.

Estimates are certainly a useful tool for making realistic commitments, but there are many others too that are equally, if not more, useful. Working at a sustainable pace, measuring data about past performance, and facilitating the genuine consensus of the whole team when committing are the way to make plans that can actually be achieved.