By Alex Yakyma.
Recently I happened to encounter a lack of specificity in a purportedly trivial situation. I was at a restaurant in Longmont, CO and wanted to start in my rather typical way, having tea with honey. Given that it was snowing, seems like a quite natural thing. I ordered "black tea with honey", the waitress asked "why black?", to which I answered that, in some countries, unless you say "black tea" or "black coffee", you will receive it with milk. Also, I noted that, this way, one could distinguish it from green tea, which is an entirely different thing. She smiled and, in a minute, I got my... you guessed it... glass of ice tea (actually with a lot of ice in it) and a little vessel with honey on the side.
I was speechless, and she disappeared before I recovered. I felt like Eric Cartman with his funny-fuse, when he wasn't able to laugh any more :) Anyways, to make a long story short, I knew what I wanted, and we even had a chat about it. I thought we had even defined everything clearly, but turns out we didn't. Sound familiar?
I think XP folks impacted on the software development industry much more significantly than we may have otherwise thought. In fact, user stories aren't a Scrum invention; this was institutionalized in XP. In particular, Ron Jeffries, defined what we know as the "3C": Card, Conversation and Confirmation - three important aspects of user stories (actually any stories, not just user ones). The "triad" actually means physical card, on which the story is written – a conversation between those who define and those who implement – to clarify detail and, finally, the acceptance criteria by which it is decided whether a job is done. This is a great conceptualization of what is necessary to keep in mind for teams. Nevertheless, the 3C itself is dependent on how effective a conversation is in terms of identifying detail; otherwise... you may get your ice tea with honey.
A useful technique to make the 3C work efficiently is Specification by Example - a collaborative approach to defining requirements based on concrete examples, instead of abstract statements. The "Second C" in this case gets recurrently supplied by examples, which become a natural way for requirements’ disambiguation for the team and stakeholders. What's important is that the "examples" are goal-driven and thus, the Conversation continues to be meaningful. So, had I said that, to warm up in such cold weather, I would need a cup of good Earl Grey tea with honey, then there likely would never have been such confusion in the first place. By the way, there indeed happens to be waiters and waitresses that have a good facilitation skill for thing like Specification by Example. But these are as rare as good facilitators among people in the software domain. Nevertheless, here's a set of simple recommendations that I give during ATDD coaching:
It is amazing how much a team can achieve when they know what they are building. User stories, as "containers" of value, in conjunction with concrete examples, represent an extremely powerful tool that makes a team extremely productive in delivering business value incrementally.
Recently I happened to encounter a lack of specificity in a purportedly trivial situation. I was at a restaurant in Longmont, CO and wanted to start in my rather typical way, having tea with honey. Given that it was snowing, seems like a quite natural thing. I ordered "black tea with honey", the waitress asked "why black?", to which I answered that, in some countries, unless you say "black tea" or "black coffee", you will receive it with milk. Also, I noted that, this way, one could distinguish it from green tea, which is an entirely different thing. She smiled and, in a minute, I got my... you guessed it... glass of ice tea (actually with a lot of ice in it) and a little vessel with honey on the side.
I think XP folks impacted on the software development industry much more significantly than we may have otherwise thought. In fact, user stories aren't a Scrum invention; this was institutionalized in XP. In particular, Ron Jeffries, defined what we know as the "3C": Card, Conversation and Confirmation - three important aspects of user stories (actually any stories, not just user ones). The "triad" actually means physical card, on which the story is written – a conversation between those who define and those who implement – to clarify detail and, finally, the acceptance criteria by which it is decided whether a job is done. This is a great conceptualization of what is necessary to keep in mind for teams. Nevertheless, the 3C itself is dependent on how effective a conversation is in terms of identifying detail; otherwise... you may get your ice tea with honey.
A useful technique to make the 3C work efficiently is Specification by Example - a collaborative approach to defining requirements based on concrete examples, instead of abstract statements. The "Second C" in this case gets recurrently supplied by examples, which become a natural way for requirements’ disambiguation for the team and stakeholders. What's important is that the "examples" are goal-driven and thus, the Conversation continues to be meaningful. So, had I said that, to warm up in such cold weather, I would need a cup of good Earl Grey tea with honey, then there likely would never have been such confusion in the first place. By the way, there indeed happens to be waiters and waitresses that have a good facilitation skill for thing like Specification by Example. But these are as rare as good facilitators among people in the software domain. Nevertheless, here's a set of simple recommendations that I give during ATDD coaching:
- Refine requirements collaboratively as a team, involve external stakeholders as much as possible; keep in mind that your co-dependent agile team is just another "stakeholder", so invite some representatives.
- Include the Specification Workshop (where Specification by Example actually comes into play) into every backlog grooming and sprint planning session.
- Actively use BVIRs (whiteboards, flipcharts, etc.).
- Use tables to represent the variations in data, flow conditions - virtually everything. Table format is the most powerful collaborative tool for refining requirements. Regardless of whether it happens later, it may or may not be represented in a table format in your ATDD tool.
- Do not allow any abstractions in the examples. Avoid those "X"s and "Y"s etc. at all cost. You will be surprised how much your team will learn about the seemingly familiar user story once they replace all Xs and Ys with real values.
- Stay timeboxed story-wise and move to the next story every 10-15 minutes. If not done with the story, no worries - you can return to it. Just don't let it go too deep and consume too much time.
- Capture all agreed upon examples - these are your acceptance tests. Capture all open questions (to stakeholders or otherwise) and resolve them first.
- Have Specification Workshops at every iteration - team self-discipline is key here. Scrum Masters can find this a real challenge for their facilitation, coaching and mentoring skills, which assist their team in adopting and sustaining Specification by Example as an effective cadence based activity.
It is amazing how much a team can achieve when they know what they are building. User stories, as "containers" of value, in conjunction with concrete examples, represent an extremely powerful tool that makes a team extremely productive in delivering business value incrementally.
