Acceptance Criteria is used to provide the test cases so that developers can be verify their code

against requirement .

To plan a release, the customer team starts by prioritizing the stories. While prioritizing they will
want to consider:

• The desirability of the feature to a broad base of users or customers

• The desirability of the feature to a small number of important users or customers

• The cohesiveness of the story in relation to other stories. For example, a “zoom out” story may not
be high priority on its own but may be treated as such because it is complementary to “zoom in,”
which is high priority.

Each story is assigned an estimate in story points, which indicates the size and complexity of the
story relative to other stories. So, a story estimated at four story points is expected to take twice as
long as a story estimated at two story points.

The release plan is built by assigning stories to the iterations in the release. The developers state
their expected velocity, which is the number of story points they think they will complete per
iteration. The customer then allocates stories to iterations, making sure that the number of story
points assigned to any one iteration does not exceed the expected team velocity.

Acceptance testing is the process of verifying that stories were developed such that each works
exactly the way the customer team expected it to work.

A dedicated and skilled tester should be included on the customer team for the more technical of
these tasks.

Writing tests early is extremely helpful because more of the customer team’s assumptions and
expectations are communicated earlier to the developers.

• Velocity is the amount of work the developers can complete in an iteration.

• The sum of the estimates of the stories placed in an iteration cannot exceed the velocity the
developers forecast for that iteration.

• If a story won’t fit in an iteration, you can split the story into two or more smaller stories.

What are the three parts of a user story? Answer: Card, Conversation, and Confirmation
Why would you want to write tests on the back of a story card?

Answer: Writing tests on the back of a card is a great way for the customer to communicate her
expectations and assumptions about a story

A good story is:

• Independent: As much as possible, care should be taken to avoid introducing dependencies

When presented with this type of dependency, there are two ways around it:

• Combine the dependent stories into one larger but independent story

• Find a different way of splitting the stories

If you don’t want to combine the stories and can’t find a good way to split them, you can always take
the simple approach of putting two estimates on the card: one estimate if the story is done before
the other story, a lower estimate if it is done after. E.g Credit Card

• Negotiable: Stories are negotiable. They are not written contracts or requirements that the
software must implement. Story cards are short descriptions of functionality, the details of which are
to be negotiated in a conversation between the customer and the development team. Because story
cards are reminders to have a conversation rather than fully detailed requirements themselves, they
do not need to include all relevant details

If we think about the story card as a reminder for the developer and customer to have a
conversation, then it is useful to think of the story card as containing:

• a phrase or two that act as reminders to hold the conversation

• notes about issues to be resolved during the conversation

Details that have already been determined through conversations become tests. Tests can be noted
on the back of the story card if using note cards or in whatever electronic system is being used

• Stories may be annotated with details, but too much detail obscures the meaning of the story and
can give the impression that no conversation is necessary between the developers and the
customer. • One of the best ways to annotate a story is to write test cases for the story

• Valuable to users or customers

The best way to ensure that each story is valuable to the customer or users is to have the customer
write the stories. Customers are often uncomfortable with this initially—probably because
developers have trained them to think of everything they write as something that can be held
against them later. (“Well, the requirements document didn’t say that…”) Most customers begin
writing stories themselves once they become comfortable with the concept that story cards are
reminders to talk later rather than formal commitments or descriptions of specific functionality.

.
• Estimable

There are three common reasons why a story may not be estimatable:

1. Developers lack domain knowledge.

2. Developers lack technical knowledge.

3. The story is too big.

No one on the team had done that so there was no way to estimate the task. The solution in this
case is to send one or more developers on what Extreme Programming calls a spike, which is a brief
experiment to learn about an area of the application. During the spike the developers learn just
enough that they can estimate the task. The spike itself is always given a defined maximum amount
of time (called a timebox), which allows us to estimate the spike. In this way an unestimatable story
turns into two stories: a quick spike to gather information and then a story to do the real work.

Even though they are too big to estimate reliably, it is sometimes useful to write epics such as “A Job
Seeker can find a job” because they serve as placeholders or reminders about big parts of a system
that need to be discussed. If you are making a conscious decision to temporarily gloss over large
parts of a system, then consider writing an epic or two that cover those parts. The epic can be
assigned a large, pulled–from–thin–air estimate.

• Small

The ultimate determination of whether a story is appropriately sized is based on the team, its
capabilities, and the technologies in use.

Splitting Stories

Epics typically fall into one of two categories: • The compound story • The complex story A
compound story is an epic that comprises multiple shorter stories.

There are normally many ways to disaggregate a compound story. The preceding disaggregation is
along the lines of create, edit, and delete, which is commonly used. This works well if the create
story is small enough that it can be left as one story. An alternative is to disaggregate along the
boundaries of the data. To do this, think of each component of a resume as being added and edited
individually

The complex story is a user story that is inherently large and cannot easily be disaggregated into a
set of constituent stories. If a story is complex because of uncertainty associated with it, you may
want to split the story into two stories: one investigative and one developing the new feature.

Complex stories are also common when developing new or extending known algorithms.

Consider Putting the Spike in a Different Iteration When possible, it works well to put the
investigative story in one iteration and the other stories in one or more subsequent iterations.
Normally, only the investigative story can be estimated. Including the other, non-estimatable stories
in the same iteration with the investigative story means there will be a higher than normal level of
uncertainty about how much can be accomplished in that iteration.

Combining Stories

Sometimes stories are too small. A story that is too small is typically one that the developer says she
doesn’t want to write down or estimate because doing that may take longer than making the
change. Bug reports and user interface changes are common examples of stories that

• Testable

Untestable stories commonly show up for non-functional requirements, which are requirements
about the software but not directly about its functionality. For example, consider these non-
functional stories:

• A user must find the software easy to use.

• A user must never have to wait long for any screen to appear.

Whenever possible, tests should be automated. This means strive for 99% automation, not 10%. You
can almost always automate more than you think you can. When a product is developed
incrementally, things can change very quickly and code that worked yesterday can stop working
today. You want automated tests that will find this as soon as possible.

USER ROLES

While each user comes to your software with a different background and with different goals, it is
still possible to aggregate individual users and think of them in terms of user roles. A user role is a
collection of defining attributes that characterize a population of users and their intended
interactions with the system.

Naturally, there will be some overlap between different user roles. They may use the same feature
of the software. They may use them in different ways and at different frequencies, but much of how
they use the system will be similar.

Use the following steps to identify and select a useful set of user roles:

• Brainstorm an initial set of user roles

To identify user roles, the customer and as many of the developers as possible meet in a room with
either a large table or a wall to which they can tape or pin cards.

When a new role card is placed, the author says the name of the new role and nothing more. Since
this is a brainstorming session, there is no discussion of the cards or evaluation of the roles. Rather,
each person writes as many cards as he or she can think of. There are no turns, you don’t go around
the table asking for new roles. Each participant just writes a card whenever she thinks of a new role.
A User Role Is One User When brainstorming a project’s roles, stick to identifying roles that
represent a single user. For example, for the BigMoneyJobs project it may be tempting to write
stories such as “A company can post a job opening.” However, since a company as a whole cannot
use the software, the story will be better if it refers to a role that represents an individual.

• Organize the initial set

Once the group has finished identifying roles, it’s time to organize them. To do this, cards are moved
around on the table or wall so that their positions indicate the relationships between the roles.
Overlapping roles are placed so that their cards overlap. If the roles overlap a little, overlap the cards
a little. If the roles overlap entirely, overlap the cards entirely

System Roles: As much as you can, stick with user roles that define people, as opposed to other
systems. If you think it will help, then identify an occasional non-human user role. However, the
purpose of identifying user roles is to make sure that we think really hard about the users that we
absolutely, positively must satisfy with the new system. We don’t need user roles for every
conceivable user of the system, but we need roles for the ones who can make or break the success
of the project. Since other systems are rarely purchasers of our system, they can rarely make or
break the success of our system. Naturally, there can be exceptions to this and if you feel that adding
a non-human user role helps you think about your system, then add it.

• Consolidate roles

After the roles have been grouped, try to consolidate and condense the roles. Start with cards that
are entirely overlapping. The authors of overlapping cards describe what they meant by those role
names. After a brief discussion the group decides

if the roles are equivalent. If equivalent, the roles can either be consolidated into a single role
(perhaps taking its name from the two initial roles), or one of the initial role cards can be ripped up

In addition to consolidating overlapping roles, the group should also rip up any role cards for roles
that are unimportant to the success of the system

After the team has consolidated the cards, they are arranged on the table or wall to show
relationships between the roles.

• Refine the roles

It is possible to model those roles by defining attributes of each role. A role attribute is a fact or bit
of useful information about the users who fulfil the role. Any information about the user roles that
distinguishes one role from another may be used as a role attribute. Here are some attributes worth
considering when preparing any role model:

• The frequency with which the user will use the software.

• The user’s level of expertise with the domain.

• The user’s general level of proficiency with computers and software.

• The user’s level of proficiency with the software being developed.

• The user’s general goal for using the software. Some users are after convenience, others favor a
rich experience, and so on
Beyond these standard attributes you should consider the software being built and see if there are
any attributes that might be useful in describing its users.

As you identify interesting attributes for a role, write notes on the role card. When finished, you can
hang the role cards in a common area used by the team so they can be used as reminders.

Personas

Identifying user roles is a great leap forward, but for some of the more important user roles, it might
be worth going one step further and creating a persona for the role. A persona is an imaginary
representation of a user role.

Creating a persona requires more than just adding a name to a user role. A persona should be
described sufficiently that everyone on the team feels like they know the persona.

If you choose to create personas for your project, be careful that enough market and demographic
research has been done that the personas chosen truly represent the product’s target audience.

You do not need to write persona definitions for every user role. You may, however, think about
writing a persona definition for one or two of the primary user roles. If the system you are building is
such that it is absolutely vital that the product satisfy one or two user roles, then those user roles are
candidates for expansion into personas.

After you have identified user roles and possibly a persona or two, you can begin to speak in terms
of roles and personas instead of the more generic “the user.”

Writing some stories with user role or persona names does not mean that other roles cannot
perform those stories; rather, it means that there is some benefit in thinking about a specific user
role or persona when discussing or coding the story

Extreme Characters

It is very possible that considering extreme characters will lead you to stories you would be likely to
miss otherwise. So, while extreme characters may lead to new stories, it is hard to know whether
those stories will be ones that should be included in the product. It is probably not worth much
investment in time, but you might want to experiment with extreme characters

Customer Team Members are responsible for ensuring that the software does not focus
inappropriately on a subset of users.

• When writing stories you will be responsible for ensuring that each story can be associated with at
least one user role or persona.

• While developing the software, you are responsible for thinking about how different user roles
may prefer the software to behave.

Trawling for requirements leads to the mental image that requirements are captured in a fishing net
being pulled behind a boat. This metaphor works on a variety of levels.
First, it is consistent with the idea that different-sized nets can be used to capture different-sized
requirements. A first pass can be made over the requirements pond with a large mesh net to get all
the big ones. You can get a feel for the needed software from the big requirements and then make a
subsequent pass with a smaller mesh net and get the medium-sized requirements, still leaving the
small ones for later

Second, trawling for requirements expresses the idea that requirements, like fish, mature and
possibly die. Some requirements will grow in importance. Similarly, other requirements that were
once considered important will decrease in importance to the point where we can consider them
dead.

Third, just like you won’t catch all of the fish in an area by trawling, you won’t capture all of the
requirements

Finally, the metaphor of trawling for requirements captures the important reality that skill plays a
factor in finding the requirements. A skilled requirements trawler will know where to look for
requirements, while the unskilled trawler will waste time with inefficient techniques or in the wrong
locations.

Some of the most valuable techniques for creating a set of stories are:

• User interviews

There are many user proxies available; but you should obviously interview real users whenever
possible. You should also interview users who fill different user roles.

It is far better to ask open-ended questions that let respondents express more in-depth opinions.

It is equally important to ask context-free questions, which are ones that do not include an implied
answer or preference

Context-free questions do not imply an answer (“When did you stop beating your wife?”) so the
respondent does not feel a need to give the “right” answer. Open-ended questions allow detailed
responses that go beyond a simple yes or no. Open-ended, context-free questions are best because
they do not influence the response and they allow a broader range of responses than yes or no.

• Questionnaires

Questionnaires can take a long time to turn around so the project will take longer to complete.
Someone will need to aggregate and interpret the results, which means there will be some degree of
misinterpretation. Because questionnaires do not provide for true two-way communication, it will
be extremely hard for a team to get feedback as to whether it’s on the right track

• Observation

• Story-Writing workshops

As you walk through the prototype, ask questions that will help you identify missing stories, such as:
• What will the user most likely want to do next? • What mistakes could the user make here? •
What could confuse the user at this point? • What additional information could the user need?
During a story writing workshop the focus should be on quantity rather than quality.

you do not want to get bogged down in lengthy debate over each story. If a story is redundant with
or becomes replaced by a better story later, then you can just rip up the story.

Occasionally some participants in a story-writing workshop have a hard time either getting started or
moving past a sticking point. In this case it can be very beneficial to have access to competitive or
similar products.

Some participants are reluctant to speak up in front of their peers or supervisors, which is why it is
important that story ideas not be judged during these sessions. Once participants become
comfortable that their ideas will simply be noted, not debated, at this point they will contribute
more readily. Finally, let me reiterate that discussion during a user story workshop should remain at
a very high level. The goal is to write as many user stories in as short a time as possible. This is not
the time to design screens or solve problems.

USER PROXIES

When we cannot get as many users as we want to represent different perspectives of the product,
we need to resort to user proxies, who may not be users themselves but are on a project to help
represent users.

Acceptance Testing User Stories

Testing is best viewed as a two-step process:

First, notes about future tests are jotted on the back of story cards. This can be done any time
someone thinks of a new test.

Second, the test notes are turned into full-fledged tests that are used to demonstrate that the story
has been correctly and fully coded.

Acceptance tests also provide basic criteria that can be used to determine if a story is fully
implemented. Having criteria that tell us when something is done is the best way to avoid putting
too much, or too little, time and effort into it

Acceptance tests provide a great deal of information that the programmers can use in advance of
coding the story.Tests are generally written at the following times:

• whenever the customer and developers talk about the story and want to capture explicit details

• as part of a dedicated effort at the start of an iteration but before programming begins

• whenever new tests are discovered during or after the programming of the story
Ideally, as the customer and developers discuss a story, they reflect its details as tests. However, at
the start of an iteration the customer should go through the stories and write any additional tests
she can think of. A good way to do this is to look at each story and ask questions similar to the
following:

• What else do the programmers need to know about this story?

• What am I assuming about how this story will be implemented?

• Are there circumstances when this story may behave differently?

• What can go wrong during the story?

With user stories it is vital that testing be viewed as part of the development process, not something
that happens “after coding is done.” Specifying tests is often a shared responsibility of a product
manager and a tester. The product manager will bring her knowledge of the organizational goals
driving the project; the tester will bring his suspicious mindset. At the start of an iteration they will
get together and specify as many initial tests as they can think of. But it doesn’t stop there, and it
doesn’t stop with them getting together once a week. As the details of a story are worked out,
additional tests are specified.

The Framework for Integrated Test

Acceptance tests are meant to demonstrate that an application is acceptable to the customer who
has been responsible for guiding the system’s development. This means that the customer should be
the one to execute the acceptance tests. Minimally, acceptance tests should be executed at the end
of each iteration. Because working code from one iteration may be broken by development in a
subsequent iteration, it is important to execute acceptance tests from all prior iterations. This means
that executing acceptance tests gets more time consuming with each passing iteration. If possible,
the development team should look into automating some or all of the acceptance tests.

Writing Good Stories

A far better approach is to write the replacement stories such that each provides some level of end–
to–end functionality. Bill Wake (2003a) refers to this as “slicing the cake.” Each story must have a
little from each layer.

Stories that represent a full slice of cake are to be preferred over those that do not. There are two
reasons for this. First, exercising each layer of an application’s architecture reduces the risk of
finding last minute problems in one of the layers. Second, although not ideal, an application could
conceivably be released for use with only partial functionality as long as the functionality that is
included in the release slices all the way through the system.

A closed story is one that finishes with the achievement of a meaningful goal and that allows the
user to feel she has accomplished something.

The desire to write closed stories has to be tempered against competing needs. Remember that
stories also need to be small enough to be estimatable and small enough to be conveniently
scheduled into a single iteration. But stories must also be large enough that you avoid capturing
details about them any earlier than necessary

the practice of annotating a story card with “Constraint” for any story that must be obeyed rather
than directly implemented.

Other examples of constraints are: • Do not make it hard to internationalize the software if needed
later. • The new system must use our existing order database. • The software must run on all
versions of Windows. • The system will achieve uptime of 99.999%. • The software will be easy to
use.

Acceptance tests can be written to ensure the constraint is not violated