A few weeks ago, I was having a conversation with a co-worker about his children and their babysitter. This babysitter had let his children eat too much candy, and by the time he and his wife came home, the kids were too wound up to go to bed. This led to my co-worker making a pronouncement: “The first requirement of a babysitter is to make sure the kids are asleep by the time we get home!”
I couldn’t help myself. I responded, “Really? Isn’t the first job of a babysitter to make sure the kids are alive and unharmed at the end of the evening?”
Perhaps this was not the most sensitive thing to say. But it made me think about how often we expect other people to have the same expectations we do. And since I develop software for a living, I started thinking about that in relation to our development process.
We often take requests from our PDF and eBook customers – requests for enhancements, for customizations or for help developing their applications. When turning them into manageable units of work, we have requirements in mind: parameters that whatever we’re doing must fulfill. Many of these are explicit: The project has to fit into the budget. The end product has to meet relevant safety regulations. The customer’s bug has to be fixed by this change.
But it’s easy to realize that there are many, many requirements we never state, because they would be absurd. A list of such things sounds like a Monty Python sketch: The end product should NOT cause the building to be overrun with meadow voles. Users of the product can wear any kind of headgear, not just a red striped Ascot cap. The customer’s document will be preserved rather than be transformed into a spear of asparagus.
Obviously, these would all be insane things to list in the requirements for a project. Leaving things out seems risky…but really, aren’t we defined by how we filter information? Our intellect is shaped by our ability to ignore what’s irrelevant and trust we can safely ignore it until necessary. How do we determine what to include and what to leave out?
When I asked my Product Manager Brandon Haugen how he makes such decisions when writing acceptance criteria, he offered this list:
Don’t state things that I think are always part of the project
Certain things we need and don’t state fall under the category of ‘good working habits’. This includes providing documentation for new APIs (or updating documentation for changed APIs), and adding unit tests for new or changed code. Stating these every time can imply that there are cases where they are not required. (This might be true on occasion, but those should still be considered exceptional cases.)
Don’t state things that I want to always be part of the project
This is really a way of saying that some things need to become good working habits. It’s easy to get focused on fixing the bug or adding the feature, and forget about the ‘extras’. This is one reason why strategies like test-driven development (or writing the documentation first) can be useful: they force you to do the right thing before you forget.
State things that I think are not obvious to me
Every case has unique requirements. There are things that you don’t think of at first glance. There are things that only one person knows (after talking to the customer, for example). These need to be shared explicitly, every time, lest they get ignored before the work is declared ‘finished’.
State things that are clear definitions of what would be a successful product
State descriptions of how the thing will be used
It helps to get detailed and explore how this thing we’re making will actually get used. This connects you with the customer, by asking questions like:
- What will the user need to know to use this method?
- What will they expect to receive in return?
- How will they know if there is a problem?
These are the kind of questions that reveal our hidden assumptions. If we don’t understand what we’re all expecting at the end of the evening, who knows what you might find when you get home?