Skip to main content
Project Management

Return to Answer

Commonmark migration
Source Link
Community Bot
Community Bot
  • 1

Flater's answer is really good; let me add something that will also help: Acceptance Criteria (AC).

Acceptance Criteria

Every single story should have Acceptance Criteria, describing the functional effects of the story with a binary (true/false) answer.

If a story is incorrect or lacking details, then this is the fault of the team during grooming/planning. Stories that aren't developer-ready (e.g, not clear or lacking details) should not be put into the sprint.

This will help your Tester and your Developer. The tester will know what things to definitely test and the developer will know which functionality is required.

###Example

Example

(if the wireframe puts a blue color button, he will produce a green color button and spend time justifying why his color is better). And he never inform or discuss with anyone about his deviation from agreed requirements.

Nope. Once a story is put in the sprint it is fixed and no changes. The time to change the story is during grooming and/or planning.

Acceptance Criteria might look like:

  1. GIVEN the user is logged in WHEN they click the menu item to go to the settings page THEN they should see a blue (#0000ff) submit button.
  2. GIVEN the user is logged in and on the settings page WHEN they click the submit button THEN the lights for Flood Control Dam #3 turn on.

When you review the story at the end of the sprint, you check the acceptance criteria. IF ANY AC ARE FALSE, THE STORY IS NOT DONE AND GOES BACK TO THE BACKLOG. The branch is not merged (you are branching for every story, right?) and that's the end of it.

If Tom argues the button should be green, then that is a new story and it needs to specify the business value (ask Tom to provide this and see what he says).

Flater's answer is really good; let me add something that will also help: Acceptance Criteria (AC).

Acceptance Criteria

Every single story should have Acceptance Criteria, describing the functional effects of the story with a binary (true/false) answer.

If a story is incorrect or lacking details, then this is the fault of the team during grooming/planning. Stories that aren't developer-ready (e.g, not clear or lacking details) should not be put into the sprint.

This will help your Tester and your Developer. The tester will know what things to definitely test and the developer will know which functionality is required.

###Example

(if the wireframe puts a blue color button, he will produce a green color button and spend time justifying why his color is better). And he never inform or discuss with anyone about his deviation from agreed requirements.

Nope. Once a story is put in the sprint it is fixed and no changes. The time to change the story is during grooming and/or planning.

Acceptance Criteria might look like:

  1. GIVEN the user is logged in WHEN they click the menu item to go to the settings page THEN they should see a blue (#0000ff) submit button.
  2. GIVEN the user is logged in and on the settings page WHEN they click the submit button THEN the lights for Flood Control Dam #3 turn on.

When you review the story at the end of the sprint, you check the acceptance criteria. IF ANY AC ARE FALSE, THE STORY IS NOT DONE AND GOES BACK TO THE BACKLOG. The branch is not merged (you are branching for every story, right?) and that's the end of it.

If Tom argues the button should be green, then that is a new story and it needs to specify the business value (ask Tom to provide this and see what he says).

Flater's answer is really good; let me add something that will also help: Acceptance Criteria (AC).

Acceptance Criteria

Every single story should have Acceptance Criteria, describing the functional effects of the story with a binary (true/false) answer.

If a story is incorrect or lacking details, then this is the fault of the team during grooming/planning. Stories that aren't developer-ready (e.g, not clear or lacking details) should not be put into the sprint.

This will help your Tester and your Developer. The tester will know what things to definitely test and the developer will know which functionality is required.

Example

(if the wireframe puts a blue color button, he will produce a green color button and spend time justifying why his color is better). And he never inform or discuss with anyone about his deviation from agreed requirements.

Nope. Once a story is put in the sprint it is fixed and no changes. The time to change the story is during grooming and/or planning.

Acceptance Criteria might look like:

  1. GIVEN the user is logged in WHEN they click the menu item to go to the settings page THEN they should see a blue (#0000ff) submit button.
  2. GIVEN the user is logged in and on the settings page WHEN they click the submit button THEN the lights for Flood Control Dam #3 turn on.

When you review the story at the end of the sprint, you check the acceptance criteria. IF ANY AC ARE FALSE, THE STORY IS NOT DONE AND GOES BACK TO THE BACKLOG. The branch is not merged (you are branching for every story, right?) and that's the end of it.

If Tom argues the button should be green, then that is a new story and it needs to specify the business value (ask Tom to provide this and see what he says).

Source Link
BryanH
BryanH
  • 347
  • 2
  • 9

Flater's answer is really good; let me add something that will also help: Acceptance Criteria (AC).

Acceptance Criteria

Every single story should have Acceptance Criteria, describing the functional effects of the story with a binary (true/false) answer.

If a story is incorrect or lacking details, then this is the fault of the team during grooming/planning. Stories that aren't developer-ready (e.g, not clear or lacking details) should not be put into the sprint.

This will help your Tester and your Developer. The tester will know what things to definitely test and the developer will know which functionality is required.

###Example

(if the wireframe puts a blue color button, he will produce a green color button and spend time justifying why his color is better). And he never inform or discuss with anyone about his deviation from agreed requirements.

Nope. Once a story is put in the sprint it is fixed and no changes. The time to change the story is during grooming and/or planning.

Acceptance Criteria might look like:

  1. GIVEN the user is logged in WHEN they click the menu item to go to the settings page THEN they should see a blue (#0000ff) submit button.
  2. GIVEN the user is logged in and on the settings page WHEN they click the submit button THEN the lights for Flood Control Dam #3 turn on.

When you review the story at the end of the sprint, you check the acceptance criteria. IF ANY AC ARE FALSE, THE STORY IS NOT DONE AND GOES BACK TO THE BACKLOG. The branch is not merged (you are branching for every story, right?) and that's the end of it.

If Tom argues the button should be green, then that is a new story and it needs to specify the business value (ask Tom to provide this and see what he says).