I realize I go on incessantly about what a revelation Elisabeth Hendrickson’s “Introduction to Acceptance Test Driven Development” class was for me. I wanted to write about areas where I’ve seen opportunities to benefit from implement it. But first I’d like to give some background of what I learned from this course.
In a nutshell ATDD (Acceptance Test Driven Development) involves bringing every team member that will touch a user story together at the beginning of a sprint to discuss the story to outline acceptance criteria and attain a shared understanding of the stakeholder’s vision.
There is a lot more to ATDD to discuss however for the sake of brevity I’d like to focus on the aspect that excited me the most, story workshops.
In a story workshop every team member who will touch the user story is gathered to discuss details of the story. One person facilitates the discussion, and after the story is described, testers and programmers ask questions and share concerns with the stakeholder. The end goal is to have shared understanding through examples of the stakeholder’s expectations. Programmers might ask if an implementation strategy is acceptable, testers almost certainly will discover areas of risk in the story’s description.
For the purposes of this class Elisabeth ran us through a few mock story workshops during which Dan Snell volunteered to play the part of the stakeholder. This was a brilliant way to teach by doing. We uncovered many interesting aspects of the story workshop that were best illustrated by allowing the group to collaborate on this mock story.
Some of the things we uncovered may seem rudimentary and obvious. When defining acceptance criteria it’s important not to take these important details for granted. Other things were less predictable. As testers in the room began to come up with test cases Elisabeth wrote them down on her flip chart. Some test cases were too deep to merit being included in basic acceptance. But mostly the test cases were simple. It may seem like a small thing to stand up and say “If the user inputs a date which occurs in the past, and it still posts a listing, this story fails acceptance.” until this seemingly obvious assumption is immediately shot down by the stakeholder in the room. She might say “I never thought to write that case into the story, but now that you mention it, I want it to post outdated listings.”
Maybe adding this feature is so involved that the engineer in the room pipes up and says “If you want me to code something that will allow an expired listing to be created it will conflict with existing code and require a significant refactor.” Maybe the stakeholder demands this feature. She can most certainly have it, but the effort to create and test it will drive it well out of scope for the story. In this case a new story is born and we move on to wrapping up the story in question.
One of the testers in the front row actually exclaimed in mock-frustration “I don’t care it’s your product!”
This simple story resulted in a lot of discussion. Elisabeth was flipping that flip chart and taping paper to the wall as quickly as we were defining criteria. In the end we felt like we had achieved a shared understanding of what the stakeholder wanted to get from the story. Every boundary we could think of at the time was addressed and accepted or rejected by the stakeholder. This didn’t mean the story was chiseled in stone, but I believe by having the story workshop we significantly reduced the odds that changes would be needed. Or if changes were needed it would not be due to a lack of communication. I would imagine that this understanding would reduce the amount of discussion necessary later when changes are needed.
During sprints I see a need for this kind of shared understanding. I find issues when testing that are not bugs but might be areas that might confuse a user.
I always take these concerns to the stakeholder and sometimes they tell me they are perfectly happy with the story the way it is. But sometimes they decide to accept my suggestion and make a change. When that happens the dev has to double his effort. He now has to remove what he did and replace it with the change. I think this is where a team pays the cost of not having story workshops.
Alternatively a programmer while trying to implement something defined in a wire frame or a user story might discover something unforeseen that requires diverting from the defined criteria. I see this sometimes in story notes (e.g. “This story is ready to be tested, as per my discussion with (the programmer) these changes to the user story were made.”
Of course it’s hard to quantify that cost. Story workshops are definitely expensive. A complex story workshop can take hours to wrap up. Lean/agile methodologies abhor rigorous documentation and heavy process. This can make story workshops a tough sell. How does one explain that we’re not proposing to create a tome of specifications for each story. We’re not trying to revert to a waterfall process. We’re not slowing the process down with this story workshop, ultimately we’re trying to speed it up. Much like test driven development it seems like a lot of overhead at the start of the project but I suspect, like TDD, the end result can be increased throughput and improved quality.
There is a lot more to ATDD than the story workshop I’ve described here and as I learn more about those aspects I’ll share them in this blog. In 10 days or so I’ll be taking what I’ve learned and holding my first mock story workshop with my product and development teams. Hopefully, despite having taken her class way back in October, I do Elisabeth justice. I am eager to hear other people’s experiences with this process and thoughts about this post. Please comment and discuss, as I still only have an academic understanding of ATDD. I am very eager to hear others’ real world experiences.
Yet again, I find myself posting a blog about something current rather than writing my chronological stories about moving to Seattle and my subsequent self-discovery as a tester.
