We think about what we build at different layers of abstraction. At the highest level, we have the minimum marketable feature set or MMF, which is composed of a list of features.
A feature is some value that someone gets from using the system. This may involve the fulfillment of several things in the system, which we can express as a set of acceptance tests. Each acceptance test expresses an acceptance criterion for the feature.
At this level, we are able to discuss the feature, what it does, who it’s for, and why they wanted. All of these things are good conversations to have.
Sometimes a feature will have many behaviors for components that could be built separately with their own acceptance criteria. In these cases, I like to split out these behaviors so that my milestones aren’t so big and building out behaviors based on acceptance criteria keeps me focused on writing code that’s of maximum value to my users.
Writing software to fulfill acceptance criteria keeps us focused on producing software that generates value for users. I find that I get lost less and so I write far less cruft and the code that I do write tends to have fewer defects because I’m much clearer on what the code is supposed to do.
Even though I’m often just a team of one, I still find the doing acceptance test-driven development and splitting behaviors on acceptance criteria to be useful practices.
Actually, I always work with a Product Owner when I do development. He is the Product Owner in my head. I have no trouble wearing the Product Owner hat when I do development but it took me many years to cultivate this skill.
Today I almost always do test-first development when I build software and I often get to do acceptance test-driven development, as well. I find that both are extremely valuable for understanding what needs to be built and giving me a context for building it in a way that allows me to verify my progress and understand it as I go so that I can rapidly implement it.
An acceptance test is an embodiment of a single acceptance criterion. We want to build out behaviors in the system based upon acceptance criteria because that’s when we derive the value from the behaviors we’re building.
In a lot of ways, acceptance test-driven development is about the value to me. It’s about the value of the features that we are building and being able to see our progress building out that value and getting on the same page with our Product Owners. This makes acceptance test-driven development one of the highest value activities that I engage in when I do software development.
Sometimes I write more acceptance tests but mostly I want to ensure that the basic acceptance tests I need for a system are there and those are the ones based upon the major acceptance criteria that my Product Owner gives me. This forces us to have a good conversation about what the most value is from the work that our team can provide and once we start to have this conversation I find that the team gives the Product Owner more of what they want in the Product Owner is more able to articulate to the team what the system should do.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
Previous Post: « Use Examples
Next Post: Make Each Test Unique »