blob: 7726356eab0de766a17fb6654577b8de83bdead4 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<!-- VERSION rmc:7.1.0 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<!-- START NON-TRANSLATABLE -->
<title>\xp\tasks\write_user_story.xmi</title>
</head>
<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
<body>
Element Name: write_user_story.xmi<br/><br/>
<!-- END NON-TRANSLATABLE -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: presentationName<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:presentationName,{62CFC55C-3151-46CB-8886-F3DBD552ABC4} CRC: 2275206683 -->Write User Story<!-- END:presentationName,{62CFC55C-3151-46CB-8886-F3DBD552ABC4} -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: purpose<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:purpose,-cqTu_uwmZrF3sFspx465XQ CRC: 4107200870 --><a id="XE_write_user_story__activity_definition" name="XE_write_user_story__activity_definition"></a>
<ul>
<li>
To specify a specific behavior of the system from a user perspective.
</li>
</ul><!-- END:purpose,-cqTu_uwmZrF3sFspx465XQ -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: name<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:name,_oQZEIGE-EdqnIZeW8YpHcA CRC: 2663915158 --> Define System Behavior <!-- END:name,_oQZEIGE-EdqnIZeW8YpHcA -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: sectionDescription<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:sectionDescription,_oQZEIGE-EdqnIZeW8YpHcA CRC: 4265570140 --><a id="Step1" name="Step1"></a>
<p>
A user story is a brief description of a feature of the system. Stories are small, taking only a week or two to
develop. The best stories provide direct business value. When stories are too big, they must be split. Consequently, it
may take multiple stories to provide business value. In this case, the individual stories need to demonstrate to the
customer that the team is making progress toward the desired business value.
</p>
<p>
There is no need for a lot of detail in the description. The details will be flushed out when the acceptance tests for
this story are defined. Typically, XP user stories are written on small index cards, one story per card.
</p><!-- END:sectionDescription,_oQZEIGE-EdqnIZeW8YpHcA -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: name<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:name,_oQZEIWE-EdqnIZeW8YpHcA CRC: 3690582602 --> Define Customer Test <!-- END:name,_oQZEIWE-EdqnIZeW8YpHcA -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: sectionDescription<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:sectionDescription,_oQZEIWE-EdqnIZeW8YpHcA CRC: 3641822092 --><a id="Step2" name="Step2"></a>
<p>
Each user story will have a set of conditions or acceptance criteria to fulfill before it is considered done.
Basically, an acceptance criterion defines an interaction scenario between the user and the system. There is usually
more than one possible scenario or acceptance test criterion for a typical story. The acceptance test criteria are
converted into <a class="elementLinkWithUserText"
href="./../../xp/tasks/automate_acceptance_test,{E614ED93-AE72-4FD1-B459-C508CE1C536F}.html"
guid="{E614ED93-AE72-4FD1-B459-C508CE1C536F}">automated customer tests</a> when the story is being implemented.
</p>
<p>
For simplicity, the test criteria are often written natural language. However, this makes them prone to
misinterpretation. To address this issue, some teams provide simple tools that allow the customer to write the
acceptance tests criteria in a form that can be executed directly by application-specific acceptance test framework.
Ultimately, it is the responsibility of the customer to provide the customer tests
</p><!-- END:sectionDescription,_oQZEIWE-EdqnIZeW8YpHcA -->
</body>
</html>