Breaking Down Stories using ATDD

On a recent trip, I was asked how one could go about breaking down a feature request into something that was small enough to consume by the team, but that also had meaning at completion?

Let me frame this question a bit.  This was asked by someone in an organization made up of component teams that is being asked to organize for features instead.

If you are lucky and have never been in a component-based organization, then here's a primer.  In a component-based organization there exists the thinking such that if I put all of the people with specialized skills together then they can share knowledge with each other and that part of the system will have great quality and integrity because everyone working in that team will have deep knowledge which is extremely hard to obtain in a large organization.

Unfortunately, what happens is that people end up losing the big picture.  Thus, knowledge is lost, not gained.  What each part of the system provides is probably optimal for that part of the system, but may not integrate very well overall with other parts of the system.  At least, they may not know until too late when integration time comes around.  Then, an expedient choice is made due to time pressures, code becomes tightly coupled for the sake of getting the product out the door and a promise is made to refactor the code later. 

Of course, we would like to avoid sad baby.  So, if we really want to figure out how to break down stories in a meaningful way, how can we do it?  

Focus on the Goal

What is the goal of a story?  Ultimately, it's to deliver something that can be used to generate feedback.  This doesn't mean the same thing every time.  I like to think of this as a continuum.

Looking at the left side of this continuum you can think of the outcome of the story as mainly feedback for the team.  The feature is not ready to publish yet.  For instance, we might want to vet a feature workflow by focusing mainly on UI components without a real backend.  This is the lean thinking prevalent in the Lean Startup.  

Whether the goal of the story is just research, or whether it's targeted to a simple scenario such as single user or it's on the other end of the spectrum and intended to be deployed to the customer, we can use the outcome to give us some data that can qualitatively prove we have done the right thing or the wrong thing.  This is one of the main reasons for making stories small in the first place.  You want to fail fast and early!

The Benefits of the Small

There are many benefits to working in small batches.  You probably already know that it normalizes your workload, makes it easier to estimate your work and makes it easier to finish.  But, there's another very important reason to make things smaller that is often overlooked that I want to explore.

Working in the small will deliberately make your code more modular and testable.  Just think about it.  How many times have you been in the situation where you were developing some code and someone depending on your code wanted to see it.  But, you may have been reluctant because you didn't quite have all the features finished and you just wanted to handle this one last use case.  Then, when you did finally hand it over it turned out that your assumptions about some things were incorrect and you overproduced.  Now, you have to go back and make some changes, but you ignore the parts that were overproduced.  Some time later, someone else on the team has to work with it and can't sort out why there are extra methods and classes, but doesn't have time to fix it so they just add what's needed.  Before long, the complexity is up and you have become the subject matter expert.

Instead, if you focus on getting a piece of code done in a few hours, no more than half a day with tests this will demand that you simplify.  In fact, you will need some tools in your toolbox to help you.  The first tool I want to explore is acceptance test driven development (ATDD).

Breaking Down Stories the ATDD Way

When creating tasks for a story, it often helps to think about the goal and where on the continuum my goal lies.  To help discover this, think of the acceptance tests first.

Let's take a simple example.  For a VOIP phone application, I may have a feature called "Make a call" that is considered a must have feature.  Now, there are many aspects to make a call that I need to consider:

• Is this a local or long distance call?
• Should I handle international calling?
• Am I dialing via inter-office dial rules?
• Is the remote party a regular PSTN phone or is it another VOIP phone?
• Do I need to display calling name & number?
• What voice codecs do I need to support?

These are just some examples of questions that may arise.  What you should then do is simplify the story to a subset that is demonstrable within the iteration time frame.  Perhaps this would be 

Make a local call using 7 digits to a regular PSTN phone with the G.711 codec.

Now that you have constrained the requirement, let's further take into account some acceptance tests.

1. If the digits are not a valid PSTN number, then I should hear a reorder signal.
2. If the called party is active on all lines, then I should hear a busy signal.
3. If the called party does not answer, then I should continue to hear ringing until I hang up (assume no voicemail).
4. If the called party answers, then I should hear 2-way audio.
5. Hanging up ends the 2-way audio stream.

Now you have some scenarios that can help you create tasks for this story.  Obviously, there are tests to write, so there are at least 5 tasks there.  Let's just look at one and see what other tasks might evolve.

• Task: Create a test to validate reorder signal when dialed party is an invalid number.
• Task: Find a way to match reorder signal through an automated system.
• Task: Verify SIP return codes are handled.
• Task: Create code to handle protocol return codes 404 and 480 and present useful information to user.
• Task: UX flows.

Note that the above tasks don't say things that you normally do like code review, check-in code, do designs.  These are things you have to do anyway.  There's no need to point them out.

ATDD - The Group Way

It's a great idea to make this the way you do Sprint Planning.  Come up with your tests and let that drive your planning session.  This way, test is involved up front as a first class citizen and everyone is on the same page as to what done means for your user story.