Anda di halaman 1dari 2

User stories are a popular technique for capturing high-level requirements.

User stories provide


the rationale and basic description of a new feature request. The following format is the most
recognisable user story template:
As a <WHO>
I want <WHAT>
So that <WHY>
Agile teams adopting the user story technique often struggle with questions such as: WHO are
user stories produced for? WHAT do good user stories look like? WHY maintain user stories
instead of more detailed requirement specifications? To answer these questions I will recycle
the who/what/why template of user stories.

WHO wants user stories?

Project stakeholders: these individuals want an easy method to pin ideas to the product
backlog. With user stories - ideas dont need to be defined in detail the user story will
provide a placeholder for a conversation.

The end user: teams that are able to elicit requirements directly from end users can use
this technique to facilitate the discussion and documentation of feature requests. What
does the user want to do? Why?

Project Manager/Product Owner: when grooming the product backlog user stories
are much easier to prioritise than detailed requirement specifications. User stories provide
a non-technical, concise summary for the product team to decide the primacy of a feature.

WHAT are user stories?

Definition: User stories describe the desired interaction/dialogue between a user and the
system. User stories provide the users rationale for a feature.

Typical format:
o AS A [actor/user role] this can be referred to as the WHO section. Who wants
this feature? The user could be a generic actor (e.g. AS A user of the website), or
a specific user role (e.g. AS A frequent business traveller), or even another system
(AS A BACS payment system). Actors can be identified by internal discussions
within the project team identifying user roles may require more sophisticated
analysis (e.g. profiling activities by the marketing department, transaction
analysis, industry segmentations etc).
o I WANT [feature/action] this can be referred to as the WHAT section. What
does the user want? The user will typically want the system to perform a new
behaviour e.g. I WANT the ability to track an order, I WANT to pay for orders
using an AMEX card, I WANT to cancel an order without any hassle.
o SO THAT [benefit] this can be referred to as the WHY section. Why does a
user want this functionality? This section provides the justification/benefit of the
feature.

Characteristics of good user stories: the INVEST acronym is frequently used to


describe attributes of a good user story:
o
o
o
o
o
o
o

Independent
Negotiable
Valuable/Vertical
Estimable
Sized Appropriately/Small
Testable

WHY use user stories?

Requirements as an emergent property: user stories provide the Business Analyst with
a springboard for analysis. A single user story (e.g. AS A price sensitive user, I WANT to
be able to cancel my order, SO THAT I do not get charged by the bank for exceeding
their overdraft limit) can lead to multiple scenarios for the BA. What is the happy path of
this user story? What are the edge cases (e.g. what if some of the items were reduced as
part of a promotion)? What are the business rules (e.g. full refunds are only provided up
to 3 days from when the transaction was processed)? Requirements should emerge from
user stories (not vice versa) - all requirements should have a user justification.

Maintenance of the backlog: the detail of a feature is abstracted a level below user
stories. In addition user stories should have few/no dependencies (refer to the INVEST
acronym) this means that user stories are lightweight additions to the product backlog
and are therefore easy to maintain.

Available for discussion: user stories should be understandable by business users/end


users/developers/all team members. User stories facilitate cross-role discussions and
encourage open communication between various project silos.

Trees and forests: Working at a detailed level can occasionally mean that some
requirements are not identified. User stories provide a way to mitigate the probability that
user journeys are missed by the team.

Conclusion
User stories provide the team with a method to capture and discuss high-level requirements.
Good user stories follow the INVEST acronym and provide the users justification for a new
feature. Within Scrum/Agile teams user stories provide an abstraction of requirement details
this facilitates maintenance of the backlog and provides the team with a placeholder for a
conversation.

?????

Anda mungkin juga menyukai