Pages

Thursday, May 31, 2012

What is a "User Story"?

Think of a User-Story as another good way to describe a business need.
What makes a user-story special is that user-stories use following accepted format to describe the need in a brief statement.


Accepted format of User-Stories
"As a [Role]
, I want to [Action]; so that I can achieve [Benefit]"
Above format of user-stories allow us to gather uncluttered insight into the desired actual need. User stories should not include implementation details, as a user-story is simply to state the need and perceived benefit.


Key Features of a User Story

  • Everyday business language should be used.
  • Not a long elaborated explanation.
  • Statement is from the perspective of the user/beneficiary.
  • Anticipated Business value (benefit) is very clear.
  • May include additional information to reduce the risk of misunderstanding.
    [
    An additional section may be added to the standard format to state this in detail.]
  • May include success/acceptance criteria to reduce the risk of misunderstanding.
    [
    An additional section may be added to the standard format to state this in detail.]
  • User Stories should not include implementation details.



Sample User-Stories
  1. As a student, I want to create my class schedule online; so I can do it from home.
  2. As an account manager, I want to receive an email of customer comments; as soon as the comment is logged.
  3. As a farther, I want to drop my child to school; so that my child can go to school.
  4. As a marketing manager, I need to see our sales compared to industry trends; so I can understand how we are doing.
As you can see from above examples, User stories can be very simple to very complex. Large user-stories may later be broken down to smaller ones.

User-Story flow...
User-Stories should be treated as stated business needs that should be detailed, validated, debated.
Collect User-Story -> verify value -> Validate need -> Discuss alternatives -> Approve User-Story -> Detail analysis -> etc.

Since a given User-Story is somewhat of a work request, a user-story may be adjusted or rejected after details analysis or discussions.


User-Stories and Non-Functional Needs
User-Story format is clearly better suited for expressing functional needs (How a system should function from user perspective). There is much debate around using User-Stories to describe non functional needs. Non-Functional attributes of systems are... behind-the-scene features of systems; such as "must be maintainable", "design to accommodate for future extensions" etc.

Debate is around... if all non-functional requirements can be expressed in User-Story format; and how to estimate and schedule non-functional User-Stories like "Easy to Maintain", "Secure" etc.

For User-Stories adapting to non-functional points are around...
If a certain need cannot be expressed in User-Story format, then at least stay close to the central idea of "a high level brief description of [Benefit] and [Action]". And non-functional requirements being hard to estimate and schedule are not necessary a problem of User-Stories alone... and builders must find a way to deal with these anyways.


User-Stories and Agile Software Development
As user-stories can describe small chunks of implementable functionality (expected from the system), user-stories are now used in agile software development models to define implementable small pieces of work.

In Agile software development, big user stories that can be broken down into smaller user-stories are named Epics. A related collection of user stories are named Themes.




To be Practical
  1. Initially treat User Stories as high level actionable statement of need; that needs to be detailed later.
  2. Look at the [Benefit] portion of the user story first… see if the stated [Benefit] is valid.
    If the benefit is not valid, no sense in moving forward with the user story.
  3. Consider needed [Action] as only a suggested process of achieving the [Benefit]; as there could be better ways of achieving the same .
    Actual mechanism of achieving the [Benefit] can be be finalized during design.
  4. If a User-Story is too complicated or difficult to understand, rewrite to be simpler.
    User stories are supposed to be a brief clear statement; not another way of confusing everyone.
  5. Set up a user story validation and approval process before building solution based on story.
    Don’t buy into user-stories, just because someone wrote it.
  6. Use "User-Stories" as the basis for client communication.
    Stories-completed, stories-pending, story-estimates, planned v actual effort of stories etc.