The Agilist Network

Tales and Tips from Agile Software Projects

Don't Overlook the Adjectives in User Stories

Posted by kenhoward on December 19, 2008

adjectives_largeTake a look at two versions of a User Story, which are written using Mike Cohn’s popular format:

Version 1

As a customer service rep, I can calculate a customer’s account balance so I can provide it when a customer calls to request it.

Version 2

As a customer service rep, I can easily calculate a customer’s account balance so I can promptly provide it when a customer calls to request it.

There are two words added in the second version of this User Story that could potentially derail the development effort if ignored.   It’s easy to overlook adjectives and adverbs as adornments that don’t add value.    While version 1 emphasizes a functional requirement of the system, those two little words added in version 2 specify two non-functional requirements that mustn’t be overlooked.

Out of the box, Scrum and other Agile methods may not sufficiently address the handling of non-functional requirements.    The method I have always used for removing ambiguity from non-functional requirements is based on Gerald Weinberg’s writings about system attributes.   This also aligns with popular practices of Thomas Gilb.

Adjective/Adverb Promptly
Target Account balance calculation process
Measured by Number of manual steps required
Minimum acceptable 1
Maximum acceptable 4
Measured by Time from submit until calculation appears
Minimum acceptable 0.5 second
Maximum acceptable 3.0 seconds

By now, the Scrummers out there may be squirming, but hear me out.   The exercise of negotiating metrics for non-functional requirements with the Product Owner will likely result in one of two outcomes:  1) They will (painfully) specify the values, or 2) They will cede that they don’t really feel that strongly about the attribute.

I’ve heard of some folks who write user stories written explicitly for a non-functional requirement itself.    This could feel like squeezing a square peg in a round hole.   A more pragmatic approach would be to simply create a task supporting the user story above to the effect of: “Specify measurement criteria for promptly” and “Specify measurement criteria for “easily”.    The deliverable for these tasks could potentially conform to the format I described above.


2 Responses to “Don't Overlook the Adjectives in User Stories”

  1. Larry said

    I guess I’m just not a big fan of using vague adjectives, that require a bunch of people to work harder to clarify after the fact. I agree adjectives cannot be ignored, but I think more effort should be put in up front, to state exactly what one means in the first place, so that the use case is testable and quantifiable.

    How about:
    “As a customer service rep, I can access the customer’s current account balance within two mouse clicks, and generate an account balance report within 3 seconds.” (Account Balance Report defined elsewhere).

  2. Chris said

    I agree with Larry on this, having seen recent examples of vague adjectives in user stories that end up as the subject of arguments when the solution is delivered to test at the end of the timebox (sprint).

    If I was on the same continent, I’d love to hear your talk on handling non-functional requirements – something we are having some problems with.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: