Definition of Ready – Crafting ‘Ready’ User Stories: A Blueprint for Sprint Success

For a smooth sprint execution, it’s crucial to ensure that the user stories slated for inclusion are thoroughly “ready.” Introducing incomplete or poorly defined user stories into a sprint leads to implementation challenges, echoing the adage “garbage in, garbage out.” When developers tackle inadequately detailed or defined user stories, the likelihood of delivering high-quality code diminishes significantly.

A “ready” backlog item needs to be clear, feasible and testable. Sample Definition of Ready :

• User Story is clear
• User Story is testable
• User Story is feasible
• User Story Acceptance Criteria defined
• User Story dependencies identified
• User Story sized by Development Team
• Scrum Team accepts User Experience design/artefacts
• Performance criteria identified, where appropriate
• Scalability criteria identified, where appropriate
• Security criteria identified, where appropriate
• Person who will accept the User Story is identified
• Team has a good idea what it will mean to Demo the User Story

A sample user story with acceptance criteria defined

User Story: As a registered user, I want to be able to reset my password so that I can regain access to my account if I forget it.

Acceptance Criteria for the Password Reset User Story:

1. User Receives Password Reset Email:
   • Upon initiating the password reset process, the user should receive an email containing a secure password reset link.
2. Password Reset Link Expires:
   • The password reset link sent via email should expire after a specified time period (e.g., 24 hours) to enhance security.
3. User Can Reset Password:
   • Upon clicking the password reset link, the user should be directed to a secure page where they can enter a new password.
4. Password Complexity Requirements:
   • The system should enforce password complexity requirements (e.g., minimum length, use of alphanumeric characters) when the user sets a new password.
5. Successful Password Update Notification:
   • After successfully resetting the password, the user should receive a confirmation notification indicating that their password has been updated.
6. Incorrect or Expired Link Handling:
   • If the user clicks on an incorrect or expired password reset link, they should be notified and prompted to request a new password reset link.
7. Logging of Password Reset Activity:
   • Password reset activity should be logged for audit purposes, including timestamps and user identifiers.
8. Integration with Email Service:
   • The system should integrate seamlessly with the email service provider to ensure reliable delivery of password reset emails.
9. Performance Criteria:
   • The password reset functionality should have a response time of under 3 seconds under typical user load conditions.
10. Scalability Criteria:
    • The password reset feature should be designed to handle a potential increase in password reset requests without service degradation, supporting at least 10,000 concurrent requests per hour.
11. Security Criteria:
    • Password reset links should be generated using cryptographically secure methods to prevent unauthorized access or tampering.
    • The password reset process should adhere to OWASP security guidelines to mitigate common security risks, such as SQL injection and cross-site scripting (XSS).
    • All password reset transactions should be encrypted using SSL/TLS to protect sensitive user data during transmission.
12. User Documentation and Help Resources:
    • Clear instructions and help resources should be provided to guide users through the password reset process in case they encounter difficulties.

Definition of Ready:

1. User Story is clear: The purpose of the user story is well-defined and understood by the team.
2. User Story is testable: Success criteria for testing password reset functionality are clearly defined.
3. User Story is feasible: The team has assessed the technical feasibility of implementing password reset functionality within the system architecture.
4. User Story defined: The user story is documented and available for review by the team.
5. User Story Acceptance Criteria defined: Acceptance criteria, such as the ability to receive a password reset email and successfully reset the password, are clearly outlined.
6. User Story dependencies identified: Any dependencies, such as integration with email services for sending password reset links, are identified and addressed.
7. User Story sized by Development Team: The development team has estimated the effort required to implement the password reset feature.
8. Scrum Team accepts User Experience artefacts: The user interface design for the password reset feature has been reviewed and accepted by the Scrum Team.
9. Performance criteria identified, where appropriate: Performance expectations, such as response time for sending password reset emails, are defined.
10. Scalability criteria identified, where appropriate: Criteria for ensuring the password reset feature can handle a large volume of requests are specified.
11. Security criteria identified, where appropriate: Security measures, such as encryption of password reset links, are identified and implemented.
12. Person who will accept the User Story is identified: A designated product owner or stakeholder responsible for accepting the completed password reset feature is identified.
13. Team has a good idea what it will mean to Demo the User Story: The team understands what constitutes a successful demonstration of the password reset functionality, including user flows and error handling scenarios.