User story
A user story is a brief description of a system requirement from the user's
or stakeholder's perspective. User stories can be defined at a high level
and decomposed as needed into smaller stories. User stories are a simple
and straightforward way to document requirements. Because they are brief,
the overhead is low for creating and updating them as requirements change. Because
they are focused on delivering value, they are a good basis for prioritizing
and implementing.
User stories work well when a complete detailed requirements specification
is not required or desired. They tend to be relatively informal and incomplete,
leaving details to be resolved during implementation. A story does not
include all of the information that makes up the requirement. It is just enough
information to identify the requirement and to remind everyone what the story
is about. Writing can be supplemented by a photo when that makes sense. This
helps the team think of the product in terms of solving needs of real people.
Examples:
- As an ATM user, I want to use my debit card to pay my electricity bill.
- As a branch manager, I want to track transactions at my branch so that
I can identify customers to upsell.
- As a student, I want to enroll in a course so I can complete my degree.
- As an online customer, I want to search for items so I can add them to
my order.
User role
A user role represents a population of users that share similar attributes
and interaction with the system. Each different user role has different
characteristics or attributes that help identify different ways that each
interacts with system. The use of roles while writing user stories helps us
avoid writing the stories from a single user's perspective. It is typical that
we start by identifying individual users of the system, then we need to
organize, consolidate, and refine them into more generic user roles.
Conversation
Another important concept is not to worry about getting all of the details
into the story. It really needs to be a commitment to have a conversation
(actually, a lot of them). Stakeholders can make up their minds as
the story is in development. Likewise, as developers need more information
or need to ask questions, they should ask (and not expect everything to be spelled
out up front for estimating purposes). What's important is to foster a
healthy communication between stakeholders (or their proxies) and
product owners with the development team.
Confirmation
It's usual that agile teams do a lot more testing along the lines of
development, compared to traditional teams. In fact, they often write a
test before they write sufficient production code to fulfill that test, and
then they proceed develop the next iteration. These teams work very
closely together and, ideally, work closely with their stakeholders. Changing
requirements are seen as a competitive advantage, not as something that you
need to prevent, as long as you can act on them. Agile teams deliver working
software at every iteration, thereby providing concrete evidence of actual progress
on the project. Daily builds, or even builds multiple times a day, are highly
desirable. Shorter iterations are desirable, from as short as one to two weeks.
Four week-long iterations are a common recommendation, although iterations
of up to eight weeks will occur at scale.
|