However I can’t find specific documentation that spells that out. The
discussion about migrating from stories here -
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?
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.
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 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.
A more qualified person may want to answer your question
I 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.
Feature: ${1:title}
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.
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.
On Sun, Oct 26, 2008 at 10:56 AM, Stephen E. [email protected] 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.
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.
On Sun, Oct 26, 2008 at 3:56 PM, Stephen E. [email protected] wrote:
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?
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!!!
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
ithttp://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
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
