Definition of Ready

What is Definition of Ready?

Definition of Ready is the properties required for a task to be started. It has to be clear, open and transparent.

What are the perspectives that have to be covered?

• User Story / Task
• Sprint
• Test

User Story / Task Perspective

User story has to cover all necessary items which are based on INVEST principles.

Invest principles items;

• Independent(of all others)
• Negotiable(not a contract for specific feature)
• Valuable(a vertical slice - feature ownership)
• Estimable(to decent approximation)
• Small(enough to fit in a single iteration)
• Testable(even if the tests don’t exist yet)

Accept an user story is ready, below items have to covered by the user story;

• The conditions of satisfaction have been fully identified for the story.
• The story details have to be understandable by the all scrum team.
• The story has been estimated and is under a certain size which is defined by the scrum team.
• The team’s user interface designer or Product Owner has mocked up, or even fully designed, any screens affected by the story.
• All external dependencies have been resolved, whether the dependency was on another team or on an outside vendor.
• Test environment or devices which is related the story, have to be ready.

Sprint Perspective

• Prioritized sprint backlog
• Defects, user stories and other work the team has committed to are contained in the sprint backlog
• No hidden work, all backlog items have to be detailed enough for next sprint.
• All team members have calculated their individual capacity for the sprint
• All users stories meet the definition of Ready.

Test Perspective

• Implementation or Work Item;

  • Has to be delivered as an increment.
  • Has to cover all definition of done rules.

  Test environment have to be ready for related item.

How the Definition of Ready should be?

Definition of Ready may not be covered all items which ared listed above. Project members have to select necessary items for their and customer needs. The items can be extended and teams can add their own custom rules to team’s definition of ready list. The most important rule is, each team member has to be beware of the definition of ready and follow the rules.

Definition of Ready Example

• The conditions of satisfaction have been fully identified for the story.
• The story details have to be understandable by the all scrum team.
• The story has been estimated and is under a certain size which is defined by the scrum team.
• Prioritized sprint backlog
• Defects, user stories and other work the team has committed to are contained in the sprint backlog
• Product backlog items have to be approved by the product owner.

Definition of Done

What is Definition of Done?

The Definition of Done is an agreed upon set of items that must be completed before a project, user story, test case, deployment steps etc. can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done.”

What are the perspectives that have to be covered?

• Development
• Test
• Deployment
• Documentation

Development Perspective

• Code have to be written by following defined code formatting.
• Comments have to be added to explain complex solutions.
• Implementation have to be complete within defined code complexity levels
• Any other third party solution(Library, Framework etc.) which endangers CDP, should not be used in implementation.
• Before committing implementation, written code/solution have to be reviewed by at least other one developer.
• If implementation needs integration with another module and the module has not implemented during implementation, mock data or mock module should be used to test implementation.

Test Perspective

• Unit tests have to be written by developer.
• All edge cases have to be tested by the developers.
• If it is needed, to keep CI/CD pipeline alive, necessary updates have to be done on CI/CD configuration for tests.

Deployment Perspective

• Implementation has to be tested by the testers before deployment.
• Before deployment, tester has to complete all regression tests to be sure that implementation is not effects any other modules.
• Before deployment, all automated tests have to be run. If test coverage below defined coverage percentage, implementation have to be rolled back.
• If implementation uses third party solutions/app, the packages should be added for deployment environment(Docker or Yocto scripts)

Documentation Perspective

• If implementation steps have complex solutions, developers have to write a document or update existing development documents to explain their solutions properly.

How the Definition of Done should be?

Definition of Done may not be covered all items which is listed above. Project members have to select necessary items for their and customer needs. The items can be extended and teams can add their own custom rules to team’s definition of done list. The most important rule is, each team member has to be beware of the definition of done and follow the rules.

Definition of Done Example

• Code has to be written by following defined code formatting.
• Comments have to be added to explain complex solutions.
• Implementation has to be complete within defined code complexity levels
• Change log has to be updated after each completed product backlog item.

Acceptance Criteria

Acceptance criteria are the conditions that a software product must meet to be accepted by a user, a customer, or other system. They are unique for each user story and define the feature behavior from the end-user’s perspective. Well-written acceptance criteria help avoid unexpected results in the end of a development stage and ensure that all stakeholders and users are satisfied with what they get.

Main purposes of the Acceptance Criteria is clarifying the stakeholder’s requirements.

Some of the criteria are defined and written by the product owner when he or she creates the product backlog. And the others can be further specified by the team during user stories discussions after sprint planning.

• Acceptance Criteria have to be written before development starts.

• Acceptance Criteria shouldn’t be too narrow.

• Acceptance Criteria have to be achievable in one sprint iteration.

• Acceptance Criteria have to be measurable and not too broad.

• Acceptance Criteria shouldn’t contain Technical Details

• Acceptance Criteria have to be understandable by all Scrum Team members

• Acceptance Criteria have to be testable

Acceptance Criteria should contain;

• Feature scope detalization

  Acceptance Criteria define the boundaries of user stories. They provide precise details on functionality that help the team understand whether the story is completed and works as expected.

• Describing negative scenarios

  Acceptance Criteria may require the system to recognize unsafe password inputs and prevent a user from proceeding further. Invalid password format is an example of a so-called negative scenario when a user does invalid inputs or behaves unexpectedly. Acceptance Criteria define these scenarios and explain how the system must react on them.

• Setting communication

  Acceptance criteria synchronize the visions of the client and the development team. They ensure that everyone has a common understanding of the requirements: Developers know exactly what kind of behavior the feature must demonstrate, while stakeholders and the client understand what’s expected from the feature.

• Streamlining acceptance testing

  Acceptance criteria are the basis of the user story acceptance testing. Each acceptance criterion must be independently testable and thus have a clear pass or fail scenarios. They can also be used to verify the story via automated tests

• Feature estimation

  Acceptance criteria specify what exactly must be developed by the team. Once the team has precise requirements, they can split user stories into tasks that can be correctly estimated.

Acceptance Criteria Template for User Story

Scenario the name for the behavior that will be described
Given the beginning state of the scenario
When specific action that the user makes
Then the outcome of the action in “When”
And used to continue any of three previous statements

Example;

User story: As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.

Scenario: Forgot password
Given: The user has navigated to the login page
When: The user selected forgot password option
And: Entered a valid email to receive a link for password recovery
Then: The system sent the link to the entered email
Given: The user received the link via the email
When: The user navigated through the link received in the email
Then: The system enables the user to set a new password

Source: https://www.altexsoft.com/blog/business/acceptance-criteria-purposes-formats-and-best-practices/