Tired of not knowing exactly what to create or test? Get in the habit of asking the magic question “How will I know I’ve done that?” In other words, ask the Product Owner (or whatever person you have filling that role on your team) to express some acceptance criteria! Asking this question will make miserable days seem bright and sunny! Well, ok, maybe not that, but asking this question will brighten your mood. There are at least three good reasons why asking this question is important.
First, the answer clears up uncertainty. As I mentioned in my blog post Bob-ism #1 – the good developer it is very easy for developers to build the wrong product if they aren’t careful. Being careful means uncertainty on the desired functionality needs to be cleared up as early as possible. There is no such thing as the perfect Product Owner who creates 100% unambiguous stories that never generate questions. This is impossible because it absolutely should not happen. The concept behind stories is they are an invitation to a conversation. The conversation should start with “How will I know I’ve done that?” Members of agile teams need to recognize the necessity of clearing up uncertainty, and Product Owner’s need to understand the necessity of making time available to help.
Second, the answer gives acceptance criteria. Acceptance criteria are useful to every person who deals with a user story. Developers know how the code will be tested. Testers have a basis for knowing what tests to create. Wouldn’t it be nice if acceptance criteria could directly be translated into automated acceptance tests? Well, we have a class on Real World Agile Testing with Fit and FitNesse coming up. The class is basically to teach how to do that! Even if you don’t take the class, look at Fit or FitNesse as potential ways to translate between spoken language and automated tests. But all of this is based on knowing what the acceptance criteria should be, and the answer to the question “How will I know I’ve done that?” gives the criteria.
Finally, asking the question fosters collaboration. Remember, a user story is an invitation to a conversation. By asking “How will I know I’ve done that?” you have accepted the invitation. Imagine if all teams had developers, testers and Product Owners collaborating up front on stories and all being in agreement on what “done” would look like – all before a line of code was written. For those of us who have seen this in action it is truly amazing. Teams become hyper-productive. Features match customer wants and needs much more accurately. Quality improves dramatically. Morale on the team improves. All of these are downstream effects of effective and meaningful collaboration.
Let me close this post with a couple of very important caveats:
- Don’t collaborate in a vaccuum. If one person needs to ask this question, there are likely others also needing to know the answer. Make sure you have the proper people as part of the conversation. This usually means developer, tester and Product Owner are all involved.
- Capture the answer! This seems so silly to have to say, but it is quite common for people to have a conversation and not record the results anywhere. This conversation affects the user story, so capture the answer in a place people will know to look. The answer is acceptance criteria. It may even clarify some wording in the story itself. Whatever it is affects the story, so save it appropriately. Remember, knowledge in your head is lost to the rest of the team – so what happens when you aren’t available???
My user story today was “My readers want a new blog entry so that they can be more agile.” I asked myself the question “How will I know I’ve done that?” The answer was “I’ll know I’ve done that when I have a published blog entry my users can access which gives them a useful agile tip.” So the acceptance criteria are:
blog entry published users can access
- contains a useful tip
I tested the first two and they work. Did I accomplish the mission for the 3rd bullet point? I certainly hope so. If not, let me know!