Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Definition of Ready

Epic

  • The Epic is prioritized appropriately according to the Product Owner, with consideration of its risk, complexity and business value

  • The Epic is aligned with the Product Manager’s product roadmap and fulfills a part of the product’s vision

  • Initial, high-level constraints, risks and dependencies are identified for the Epic and listed in the Jira issue along with impact and proposed resolution

  • The Epic complies with the high-level architecture and IT/Business solution in scope of the company product portfolio

  • Acceptance criteria (see 5.3 - The Product Backlog) for the Epic are defined, listed and agreed upon

  • High-level estimation (T-Shirt sizes or large Story Points) has been conducted and noted for the Epic (or in hours where abstract relative estimation is not used)

  • At least 1 user story or workable Sprint Backlog item exists in the Epic in Jira

User Story

  • The User Story is refined with respect to the I-N-V-E-S-T (5.3 - The Product Backlog) mnemonic for agile software development

  • Detailed constraints and risks are identified and listed in the Jira issue along with impact and proposed resolution (including GDPR considerations)

  • Sufficient acceptance criteria and/or description (including functional requirements) have been provided for the User Story to be deemed acceptable upon completion

  • Should the User Story be accepted by a delegate of the Product Owner, then that person is explicitly indicated in the Jira issue

  • If relevant for the User Story, performance criteria are defined along with the acceptance criteria

  • If relevant for the User Story, visual / UX criteria are defined along with the acceptance criteria, such as UX visual designs, PSD/HTML files, etc. attached to the Jira issue

  • If relevant for the User Story, integration specification and schema are defined along with the acceptance criteria, such as WSDL, XSD, XML files etc. attached to the Jira issue

  • The User Story is estimated and sized in Story Points (or hours where Story Points are not used)

  • The team is aware of how to potentially realize the User Story, sees no blocking impediments and has an idea how to present a live working demo of the User Story in scope of the next Product Increment

Bug

  • The Bug is defined with a description of the flawed system behavior, indicating the steps, data and technical parameters necessary to reproduce the defect on a specified environment

  • Detailed constraints and risks are identified and listed in the Jira issue along with impact and proposed resolution (including GDPR considerations)

  • Sufficient acceptance criteria and/or description (including expected behavior or reference to the appropriate user story) have been provided for the Bug to be deemed acceptable upon completion

  • Should the Bug be accepted by a delegate of the Product Owner, then that person is explicitly indicated in the Jira issue

  • If relevant for the Bug, performance criteria are defined along with the acceptance criteria

  • If relevant for the Bug, visual / UX criteria are defined along with the acceptance criteria, such as UX visual designs, PSD/HTML files, etc. attached to the Jira issue

  • If relevant for the Bug, integration specification and schema are defined along with the acceptance criteria, such as WSDL, XSD, XML files etc. attached to the Jira issue

  • The team is aware of the area affected by the Bug and has consideration for potential root cause and/or resolution of the defect; further investigation may be necessary to determine the issue during the sprint

  • The Bug is estimated and sized in Story Points (or hours where Story Points are not used)

  • The severity of the bug has been provided

In case of 1 or 2 days off:

1. Team member will inform SM or whole Team (on daily or Team channel) when he would like to take days off.

2. Update Team calendar on Confluence Team Nova

3. Update Outlook Calendar

In case of longer holiday (longer than 3 days)

Team members have to:

1. Ask manager via email for approval (Umesha Aithappa Shetty ). Should include in 'CC' SM, PO, TL.

2. Inform Team representatives SM/TL and PO (in the same email as in point 1)

3. Update Team calendar on Confluence Team Nova

4. Update Outlook Calendar

5. Set auto response email in Outlook with information about holiday period and with whom sender should contact in case of any issue.

6. Enjoy your holiday 😊

Impediments

Inform in DSM

Additionally, SM/TL

...