http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Thanks Derick http://ayende.com/3365/my-bdd-experiment#comment6http://ayende.com/3365/my-bdd-experiment#comment6Sat, 14 Jun 2008 16:15:57 GMTDerick, This is exactly the sort of info I was looking for when I posted that. Thanks! http://ayende.com/3365/my-bdd-experiment#comment5http://ayende.com/3365/my-bdd-experiment#comment5Sat, 14 Jun 2008 01:00:43 GMTI think you are heading down the same rabbit hole that I have been going down, in terms of the stories you are writing - and it becomes problematic really quickly. the problem is that we are developers and we constantly have the developer goggles on, even when we don't think we do. so we end up writing stories in the wrong format: As a [role], I want to [Do some specific thing] so that [I can do some specific thing]. What we really need to be writing is, As a [role], I want to [goal], so that [motivation]. The difference is subtle, but has a profound impact on the stories. The major difference is in the motivation - a true motivation is not to do what you already said you want to do, or to do your job (as I've written in several stories). THe other issue is the role you've specified. "User" isn't a valid role; and perhaps "role" is the wrong word. Dan North, again, suggested the word "stakeholder". I've suggested "persona" a few times, as well. We have to keep in mind that the "motivation" is directly attributable to the role - why does this person want to accomplish the set task. a "user" just wants to "use" the system. However, a "Software developer" may want to "learn about (insert webcast topic here)". As an example, look the first two stories that you've written. You basically have "i want to see stuff so that i can see stuff". I would re-write the first two stories here, into a single story with better motivation: --------------------- As a software developer, I want to find webcasts that are relevant to me, so that I can learn more about these topics and become a better developer. Acceptance Criteria: * When displaying a webcast summary, include the following information * Name * Date Published * Short Description * When viewing the details of a webcast, display all relevant infomration about the webcast, including * Name * Date Published * Short Description * Number of Downloads * Relevant files and links * ... other stuff... * Should display the most recent webcast summary on the homepage --------------------- There are some very critical distinctions made in this story and criteria, vs. what you have originally written. Notice that the story avoid the "do this so i can do that" format. It talks about a "software developer", which is the persona or stakeholder that you are targeting with your webcasts. It also talks about wanting to learn more about the topics in the webcasts - which is ultimately why we want to watch webcasts, in the first place. The acceptance criteria is also significantly different. Notice that we've completely separated the "homepage" language into a separate criteria. This is because the word homepage begins to talk more about technical details or implementation. It's critical that we know to put the summary on the homepage, but we should not mix the behavioral criteria (displaying the summary) with the implementation criteria (display it on the homepage). Keeping these separate will give you more clearly defined criteria to work with and allow your unit tests to be more clearly written and scoped. For example, you should not need to write an integration test to view the homepage, just to test the summary display. By separating these criteria, we are not forced into that situation. ... Dan North pointed these same problems in my stories, and pointed me to this post, which helped me understand what I was doing wrong: http://iansrobinson.com/2008/06/05/rediscovering-business-benefits/ For a bit more information on my perspective in user stories and acceptance criteria, see the following post from a week or two ago: http://www.derickbailey.com/2008/05/29/UserStoryAndAcceptanceCriteriaFormatting.aspx http://ayende.com/3365/my-bdd-experiment#comment4http://ayende.com/3365/my-bdd-experiment#comment4Fri, 13 Jun 2008 13:26:22 GMTWhat?!?!? No DSL?!?! You've changed man. You've changed... ;) http://ayende.com/3365/my-bdd-experiment#comment3http://ayende.com/3365/my-bdd-experiment#comment3Fri, 13 Jun 2008 12:27:30 GMTOh no. It is not executable, and it is not a DSL. Those are notes about the story http://ayende.com/3365/my-bdd-experiment#comment2http://ayende.com/3365/my-bdd-experiment#comment2Fri, 13 Jun 2008 02:48:07 GMTAyende, Our team has been using BDD for the last four months or so, and I must admit that I am completely hooked. BDD has generated the same amount of interest for me as TDD did initially. It appears that you are aiming for executable stories. Personally, this is something that I avoid. I tend to speak about system behaviors more in the small. I still call out domain concepts in my BDD specifications, but those concepts may be much more granular than user-story level. I am working on an extensive example that I hope to have available next week. If you're interested, feel free to shoot me an email or watch my blog (www.testinfected.net). http://ayende.com/3365/my-bdd-experiment#comment1http://ayende.com/3365/my-bdd-experiment#comment1Fri, 13 Jun 2008 02:38:17 GMT