BDD and "How Are You Going to Use That Information"


Fred George has a post called “And How Are You Going to Use That Information?” that strikes at the heart of the analysis practices in Behavior Driven Development.

I’ve been looking for a question like, “and how are you going to use that information”.  My team is probably going to get really fed up hearing this particular question as I often use variants of it when trying to drive home the importance of BDD to YAGNI-avoidance.  Fred’s way makes it much easier for me.

Here’s an example from a recent release planning meeting:

Other: I’d like to see the current SVN build stamp in the footer of the app’s web pages.
Me: Why?
Other: So I can include it in feedback on the pre-alpha previews.
Me: Can you give me a story for that?

My assumption here is that once the story is surfaced, the person I’m speaking with will see that the feature won’t be valuable.

Here’s a the same conversation (theoretically) from Fred’s universe:

Other: I’d like to see the current SVN build stamp in the footer of the app’s web pages.
Me: Why?
Other: So I can include it in feedback on the pre-alpha previews.
Me: And how are we going to use that information?
Other: To track which release the feedback applies to (presumably).

Since we’ve got an extremely small number of people in our preview pool (less than 10 presently), and since we’ve got very little functionality released for preview, the build number won’t really help with the actions that we take based on feedback.

With such a small dev team, and so few previewers, and so little functionality, it’s near impossible for anyone who is invested in the project to not know what feedback pertains to.

The build number stamp is superfluous to our ability to respond to feedback and take action based on the feedback.  Our review of the inbound feedback, and the prioritization of tasks happens as a matter of agile planning, which is an information-immersive negotiation for stakeholders and designers.

No one could possibly not know what the feedback pertains to and therefore having further qualification by build number doesn’t enable us to fulfill our responsibilities any better.  It does however arbitrarily cost us the time of implementing the build number stamp.

This information might be useful to us later – when we have more releases, more features, more feedback, etc.  If we were to put in the effort to build it now, we would – in Lean terms – be incurring inventory cost.

Asking “How are you going to use that information” forces us to look at the behaviors that capitalize on that information, or that are enabled by that information.  When we just declare that we need some piece of information or other without justifying it with a concrete user story, we’re just doing model-driven or data-driven design.

When I focus first on behaviors – especially user goals as expressed based on scenarios with realistic context – the understanding of the necessary data will simply become clear and evident.  If I get distracted in the details of data-driven and model-driven analysis, I run a really high risk of accumulating unneeded inventory and its associated costs.

Drill down on behaviors.  Find out if they are real and substantial, and then figure out the data needs.  Starting at data is often a crap shoot at best.  Behaviors will surface data needs, but the opposite is almost never true – not in any substantial and meaningful way that works against incurring inventory in any case.

BDD and “How Are You Going to Use That Information”

Explore posts in the same categories: Agile Development, BDD, TDD

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: