In the old Story Runner framework the feature description had a preamble that looked like As a... I want... So that... When I was moving to cucumber I seem to remember reading somewhere that that formulation was being changed, and indeed the example here - http://github.com/aslakhellesoy/cucumber/tree/master/examples/calculator/features/addition.feature , looks like this - In order to... As a... I want to... However I can''t find specific documentation that spells that out. The discussion about migrating from stories here - http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories doesn''t say anything about it and I''ve also written features successfully using the original formulation. So I''m just curious about what the significance of the preamble is. Is it purely an aid to help the writer think correctly about what they are supposed to be describing? Does it make any real difference how it is formulated or whether it''s even present? Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081025/bd34fe67/attachment.html>
Mark Thomson wrote:> In the old Story Runner framework the feature description had a > preamble that looked like > > As a... > I want... > So that... > > When I was moving to cucumber I seem to remember reading somewhere > that that formulation was being changed, and indeed the example here - > > http://github.com/aslakhellesoy/cucumber/tree/master/examples/calculator/features/addition.feature > , > > looks like this - > > In order to... > As a... > I want to... > > However I can''t find specific documentation that spells that out. The > discussion about migrating from stories here - > > http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories > > doesn''t say anything about it and I''ve also written features > successfully using the original formulation. > > So I''m just curious about what the significance of the preamble is. Is > it purely an aid to help the writer think correctly about what they > are supposed to be describing? Does it make any real difference how it > is formulated or whether it''s even present? > > Mark. >The preamble or narrative doest not effect the actual running of the feature but like you said, it acts as an aid to answer upfront the most important question about this feature - why am I implementing it? Or in other words, what is the business value that this feature will fulfill? Along with the business value being listed having the role in the narrative is also very helpful as it places the all of the scenarios in the right context. A more qualified person may want to answer your question, but my short explanation of the change of the default narrative layout is to state the business value at the start instead of the end. However, you shouldn''t feel constrained to use that layout all the time though. Whatever communicates the business value best and most succinctly to the customer and you for a given feature is what you should use. HTH, Ben
Thanks much. Mark. Ben Mabey wrote:> <snip> > The preamble or narrative doest not effect the actual running of the > feature but like you said, it acts as an aid to answer upfront the > most important question about this feature - why am I implementing > it? Or in other words, what is the business value that this feature > will fulfill? Along with the business value being listed having the > role in the narrative is also very helpful as it places the all of the > scenarios in the right context. > > A more qualified person may want to answer your question, but my short > explanation of the change of the default narrative layout is to state > the business value at the start instead of the end. However, you > shouldn''t feel constrained to use that layout all the time though. > Whatever communicates the business value best and most succinctly to > the customer and you for a given feature is what you should use. > > HTH, > Ben > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > >
> A more qualified person may want to answer your questionI think you are plenty qualified :)> but my short > explanation of the change of the default narrative layout is to state the > business value at the start instead of the end.Exactly what I was gonna say.> However, you shouldn''t feel > constrained to use that layout all the time though. Whatever communicates > the business value best and most succinctly to the customer and you for a > given feature is what you should use.Right on. And I''d say that the preamble is so valuable that trying to give it a rigid syntactic structure could only detract value, not add it. Pat
On Oct 26, 2008, at 12:19 am, Ben Mabey wrote:> A more qualified person may want to answer your question, but my > short explanation of the change of the default narrative layout is > to state the business value at the start instead of the end.I do this, and updated my TextMate Cucumber fea<tab> to this: Feature: ${1:title} So that ${2:value} As a ${3:role} I want ${4:feature} $0 for this very reason. Putting the business value first, and not writing anything else until you''ve found it, means you don''t get to cheat and dump "it would be nice" features into the flow, then gloss over the fact they''re completely useless. Found I wrote one of these myself last week, when I wrote the "I want" bit on a card 5 mins before we went home. Took half an hour this week to realise it does nothing useful (or at least, needs doing in a completely different way). But the fact I''d written it down somehow ennobled it. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/
On Sun, Oct 26, 2008 at 5:11 AM, Ashley Moran <ashley.moran at patchspace.co.uk> wrote:> > On Oct 26, 2008, at 12:19 am, Ben Mabey wrote: > >> A more qualified person may want to answer your question, but my short >> explanation of the change of the default narrative layout is to state the >> business value at the start instead of the end. > > > I do this, and updated my TextMate Cucumber fea<tab> to this: > > Feature: ${1:title} > So that ${2:value} > As a ${3:role} > I want ${4:feature} > > $0 > > for this very reason. > > Putting the business value first, and not writing anything else until you''ve > found it, means you don''t get to cheat and dump "it would be nice" features > into the flow, then gloss over the fact they''re completely useless. Found I > wrote one of these myself last week, when I wrote the "I want" bit on a card > 5 mins before we went home. Took half an hour this week to realise it does > nothing useful (or at least, needs doing in a completely different way). > But the fact I''d written it down somehow ennobled it.Recommended reading: http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/ Cheers, David> > Ashley > > -- > http://www.patchspace.co.uk/ > http://aviewfromafar.net/ > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Sat, Oct 25, 2008 at 7:19 PM, Ben Mabey <ben at benmabey.com> wrote:> > A more qualified person may want to answer your question, but my short > explanation of the change of the default narrative layout is to state the > business value at the start instead of the end. However, you shouldn''t feel > constrained to use that layout all the time though.I prefer (and still use) the old way for grammatical reasons. Putting the dependent clause of a sentence ahead of the independent clause that it''s dependent is awkward and distracts from the reading. If enough of this we do, talk like Yoda, we all will. Wish that, I do not. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org
On Sun, Oct 26, 2008 at 10:56 AM, Stephen Eley <sfeley at gmail.com> wrote:> > I prefer (and still use) the old way for grammatical reasons. Putting > the dependent clause of a sentence ahead of the independent clause > that it''s dependent is awkward and distracts from the reading.Argh. That should have been "...that it''s dependent UPON." I believe there''s an old Internet law that states that any post bitching about grammar is guaranteed to contain at least one grammatical error, but I can''t be bothered to look it up. -- Have Fun, Steve Eley (sfeley at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org
On Oct 26, 2008, at 2:56 pm, Stephen Eley wrote:> I prefer (and still use) the old way for grammatical reasons. Putting > the dependent clause of a sentence ahead of the independent clause > that it''s dependent is awkward and distracts from the reading.To me, the benefit of the unusual order (forcing you and/or your users to think about the value before all else) outweighs the downside. And actually, I''ve never had anyone comment that this order is confusing, so it can''t be that bad.> If enough of this we do, talk like Yoda, we all will. Wish that, I > do not.But Yoda kicked ass! I want my stories to have Jedi powers in them! And light sabres! More light sabres in RSpec 1.2!!! -- http://www.patchspace.co.uk/ http://aviewfromafar.net/
On Oct 26, 2008, at 2:59 pm, Stephen Eley wrote:> I believe there''s an old Internet law that states that any post > bitching about grammar is guaranteed to contain at least one > grammatical error, but I can''t be bothered to look it up.Read too much Slashdot, you do ;) -- http://www.patchspace.co.uk/ http://aviewfromafar.net/
On Sun, Oct 26, 2008 at 3:56 PM, Stephen Eley <sfeley at gmail.com> wrote:> On Sat, Oct 25, 2008 at 7:19 PM, Ben Mabey <ben at benmabey.com> wrote: >> >> A more qualified person may want to answer your question, but my short >> explanation of the change of the default narrative layout is to state the >> business value at the start instead of the end. However, you shouldn''t feel >> constrained to use that layout all the time though. > > I prefer (and still use) the old way for grammatical reasons. Putting > the dependent clause of a sentence ahead of the independent clause > that it''s dependent is awkward and distracts from the reading. > > If enough of this we do, talk like Yoda, we all will. Wish that, I do not. >The role and a feature is secondary to the business value (and the role using the feature is more important than the feature itself). That''s why we prefer promoting it to the beginning. Without a clear vision of what the business value we might be developing crap. Think of the template as three elements in order: BUSINESS VALUE ROLE FEATURE The exact wording you use is not important. The order in which these elements appear is. There is nothing about this order that suggests that it can only be described with Yoda language. I do agree that the concrete template we''re currently using is a little awkward though. How can we improve it? Aslak> > > -- > Have Fun, > Steve Eley (sfeley at gmail.com) > ESCAPE POD - The Science Fiction Podcast Magazine > http://www.escapepod.org > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
2008/10/26 aslak hellesoy <aslak.hellesoy at gmail.com>> On Sun, Oct 26, 2008 at 3:56 PM, Stephen Eley <sfeley at gmail.com> wrote: > > On Sat, Oct 25, 2008 at 7:19 PM, Ben Mabey <ben at benmabey.com> wrote: > >> > >> A more qualified person may want to answer your question, but my short > >> explanation of the change of the default narrative layout is to state > the > >> business value at the start instead of the end. However, you shouldn''t > feel > >> constrained to use that layout all the time though. > > > > I prefer (and still use) the old way for grammatical reasons. Putting > > the dependent clause of a sentence ahead of the independent clause > > that it''s dependent is awkward and distracts from the reading. > > > > If enough of this we do, talk like Yoda, we all will. Wish that, I do > not. >This is an evolution of the Connextra story format (as a.. I want.. so that..) to put the emphasis on the value. Liz Keogh blogged about it<http://lizkeogh.com/2008/05/14/rip-as-a-i-want-so-that/>a while ago and it''s starting to catch on with the teams I work with. It has a really nice secondary effect which is that often the active participant in a story isn''t the person who benefits, and the Connextra format struggles with this. Liz''s favourite example is the capcha. No-one *wants* to type in some wobbly letters! Using the value-first format, you get something like this: In order to minimise spam on the blog site The *site administrator* Wants *a commentator* to answer a capcha when they submit a comment So now we have identified two stakeholders - the one who benefits and the one who does the work. This can be useful in understanding someone''s motivation in a scenario. Cheers, Dan> > > > > The role and a feature is secondary to the business value (and the > role using the feature is more important than the feature itself). > That''s why we prefer promoting it to the beginning. Without a clear > vision of what the business value we might be developing crap. > > Think of the template as three elements in order: > > BUSINESS VALUE > ROLE > FEATURE > > The exact wording you use is not important. The order in which these > elements appear is. There is nothing about this order that suggests > that it can only be described with Yoda language.I agree. But Yoda language it is not. Oh crap. I do agree that the concrete template we''re currently using is a> little awkward though. How can we improve it? >In order to [goal] [stakeholder] Wants [behaviour] (The Yoda variant would be [behaviour] wants :) Aslak Cheers, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081117/8b66bf71/attachment.html>