Dependencies between stories lead to prioritization and planning problems. For example, suppose the customer has selected as high priority a story that is dependent on a story that is low priority.A company can pay for a job posting with a Visa card.A company can pay for a job posting with a MasterCard.A company can pay for a job posting with an American Express card.Suppose the developers estimate that it will take three days to support the first credit card type (regardless of which it is) and then one day each for the second and third. With highly dependent stories such as these you don't know what estimate to give each story—which story should be given the three day estimate?
A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. User stories are used with Agile software development methodologies for the basis of what features that can be implemented.
Each user story is limited, so it fits on a small paper note card to ensure that it does not grow too large.
User story template
As a <role>, I want <goal/desire> so that <benefit>.
As a user I want to create organizer records, so that I can store my plans scheduled somewhere.
User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them.
Independent - stories should not be dependent on one another. Dependencies between stories lead to prioritization and planning problems.
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.
Valuable - each story must bring some business value.
Estimable – the scope of as story must be observable.
The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software.
Business analyst can be a surrogate of a customer.
User stories could also be written by developers to express non-functional requirements.
Acceptance of a story
Before a user story is to be implemented, an appropriate acceptance procedure must be written by the customer to ensure by testing or otherwise determine whether the goals of the user story have been fulfilled.
Acceptance criteria: a record with all fields specified is created and saved so some persistent state
Organizer CRUD userstories: C US 1. As a user I want to create organizer records, so that I can store my plans scheduled somewhere._____________Acceptance criteria: a record with all fields specified is created and saved so some persistent state Size: medium. Priority: highSprint: 1
Organizer CRUD userstories: R US 2. As a user I want to view the records that have a particular date, time specified on the calendar, so that I can schedule my plans._____________Acceptance criteria: System displays the records that have date specified on the calendar.Size: medium. Priority: highSprint: 1
Organizer CRUD userstories: R US 3. As a user I want to view the records with no date specified on the tasks section, so that I can view my tasks that have to schedule._____________Acceptance criteria: System displays the records that have no date specified on the tasks pane.Size: medium. Priority: mediumSprint: 1
Organizer CRUD userstories: U US 4. As a user I want to edit the records stored persistently in the app, so that I can change my plans._________Acceptance criteria: 1. System allows to edit an existing records.2. The entered/existing data is saved successfully to the persistent storage when the user saves the record.Size: big. Priority: lowSprint: 2
Organizer CRUD userstories: D US 5. As a user I want to delete records, so that I can clean up the mess.______Acceptance criteria: The record is deleted from the persistent storage and is no longer available.Size: simple.Sprint: 2