[rspec-users] Feature Size-Scope-Scale

Stephen Eley sfeley at gmail.com
Mon Mar 2 11:54:23 EST 2009

On Mon, Mar 2, 2009 at 10:07 AM, James Byrne <lists at ruby-forum.com> wrote:
> I have read a great deal about scaling features in terms of hours of
> work.  However, at my present level of inefficiency, that will probably
> result in features that are too small just as I now believe that the
> features I have now are too large.  Besides which, I seem to grasp
> examples better than metrics when conceptualizing such things.

Real features for a real project I'm working on:

Feature: View Episodes
  As a listener
  I want to see a list of episodes
  So that I can experience the joy of consuming them

Feature: Create Episode
  As a podcaster
  I want to add an episode
  So that I don't die like Emily Dickinson

Feature: Edit Episode
  As a podcaster
  I want to edit an existing episode
  So that my listeners can catch my mistakes for me

Feature: Add MP3 Enclosure
  As a podcaster
  I want to link to an MP3 file
  So that people don't confuse me for a blogger

...That's my basic feature size.  An atomic unit of work,  and
generally one that comprises a single Web interaction.  I'll usually
put down 2-3 scenarios when I make the feature file (critical success
path, and at least one exception case) and then add more if/when I
think of them.

These mostly fall out to a few hours of work each, but that seems to
be a natural consequence of thinking at an atomic level and not a
deliberate goal I'd planned for.  If one of them took days, well, it'd
take days.

> [ . . . ]  Or, as I begin to suspect, should one have separate features
> like "Add a new client"; "Deactivate an existing client"; Reactivate an
> inactive client"; "Report all active clients; ... and so forth.

Here would be my suggestion:

* Start by doing it the way you think makes the most sense.
* If it feels good and seems to result in better code done faster,
keep doing it that way.
* If it hurts, or slows you down without a quality increase, either
try changing the way you're doing it, or stop doing it entirely.
* Whenever you next run across something that you think might be a
good improvement in your working methods, repeat steps 1-3.

Penultimately it's about people and product.  But people build the
product, so ultimately it's about people.  You need to figure out what
works for you and your task at hand.  Others can offer advice or
experiences but they can't give you the right answers.

Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine

More information about the rspec-users mailing list