This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 30 lines
!!! Overview
[{$pagename}] represents a small piece of [business value] that a [Delivery Team] can deliver in an [iteration]. [{$pagename}] (and [Agile Tasks], often called features) break requirements into chunks for planning purposes. [Stories|User Story] are explicitly broken down until they can be estimated as part of XP's [Release Planning] process.[2]
While traditional requirements (like [use cases]) try to be as detailed as possible, a [{$pagename}] is defined incrementally, in three stages:
* The brief description of the need
* The conversations that happen during backlog grooming and iteration planning to solidify the details
* The tests that confirm the story's satisfactory completion
Well-formed [{$pagename}]s will meet the criteria of Bill Wake's INVEST acronym:
||Term||Description
|Independent|We want to be able to develop in any sequence.
|Negotiable|Avoid too much detail; keep them flexible so the [Delivery Team] can adjust how much of the [{$pagename}] to implement.
|Valuable|Users or customers get some [Business value] from the story.
|Estimable|The [Delivery Team] must be able to use them for planning.\\Small as Large [{$pagename}] are harder to estimate and plan. By the time of [Iteration Planning], the story should be able to be designed, coded, and tested within the [iteration].
|Testable|Document acceptance criteria, or the [Definition of Done] for the [{$pagename}], which lead to test cases.
!! Why Use User Stories?
Keep yourself expressing [business value]
* Avoids introducing detail too early that would prevent design options and inappropriately lock developers into one solution
* Avoids the appearance of false completeness and clarity
* Get to small enough chunks ([Agile Tasks]) that invite negotiation and movement in the [backlog]
* Leave the technical functions to the architect, developers, testers, and so on
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Write a Great User Story|https://help.rallydev.com/writing-great-user-story|target='_blank'] - based on information obtained 2016-12-08-
* [#2] - [What is the difference between a UseCase and XP's UserStory?|https://martinfowler.com/bliki/UseCasesAndStories.html|target='_blank'] - based on information obtained 2018-10-26-