Rookie Scrum Agile Practice Series (ii) User story acceptance

Rookie Scrum Agile Practice Series Index

Rookie Scrum Agile Practice Series (i) User story concept

Rookie Scrum Agile Practice Series (ii) User Story acceptance (this article)

Rookie Scrum Agile Practice Series (iii) organization of user stories (coming soon)

First, the status of the user story:

User Story recommendations define five states, namely, "conceived," "Approved," "in Development," "Completed," "accepted."

Only the acceptance criteria specified by the project group can be set to the "accepted" status.

Second, the user story acceptance criteria

The acceptance criteria are determined by the team. The standard may include:

• Completed All Tasks (development, testing and logging)

• Running and passing all acceptance tests

• No open defects

• Product owner has accepted

• Can be delivered to users

Complete all stories by this standard during each iteration.

User Story Acceptance Criteria entry:

iii. Writing User Stories six principles-invest

A good user story should follow the Invest principle

　　Independence (Independent)

Try to keep one user story separate from other user stories. The dependency between user stories makes planning, prioritization, and workload estimation difficult. Often we can reduce dependencies by combining user stories and decomposing user stories.

　　Negotiable (Negotiable)

If the content of a user story can be negotiated, the user story is not a contract. A user story card is just a brief description of the user story, not including too many details. Specific details are produced during the communication phase. A user story card with too much detail actually restricts communication with the user.

　　Valuable (valuable)

Each story must be valuable to the customer (both the user and the purchaser). A good way to make a user story worthwhile is to have the customer write it down. Once a customer realizes that this is a user story and is not a contract and can negotiate, they will be happy to write the story.

　　can be estimated (estimable)

The development team needs to estimate a user story to prioritize, work, and schedule plans. But it is difficult for developers to estimate the problem of the story: the lack of domain knowledge (which requires more communication), or the story is too big (then the story needs to be cut into smaller).

　　Short (Small)

A good story should be as short a workload as possible, preferably not more than 10 ideal people/days of work, at least to ensure that in an iteration or sprint can be completed. The larger the user story, the greater the risk of scheduling, workload estimation, and so on.

　　Testability (testable)

A user story can be tested so that it can be done. If a user story can't be tested, then you don't know when it's going to be done. An example of a non-testable user story: The software should be easy to use.

Rookie Scrum Agile Practice Series (ii) User story acceptance