Let’s play a game

In any project, regardless of the management methodology, there are two things that need to be decided up front by all the stakeholders:

  • Requirements: what is the structure?
  • Delivery: when it is ready to ship?

In SCRUM we call them:

  • Definition of Ready
  • Definition of Done

For each one we have a specific template that we built in time, based on experience and lessons learned.

Why they are so important?

rules
Would you play a game without knowing the rules?

Even from childhood we are comfortable with playing the game only if we know the rules.

Each project is a game : you either win (the delivery is exactly what the client expected) or lose  (you end up in ping-pongs on each requirement, or endless discussions and arguments on what was delivered)

Definition of Done and Definition of Ready  are vital for project success simply because everyone needs to know the rules. More preciseley : establish up front what needs to be done for each requirement in order to be approved.

Audience: Project Managers, Product Managers, SCRUM Team members| Estimated reading time: 5 mins

Definition of Ready

The Definition of Ready (DoR) applies to Items in the Backlog (e.g. User Stories) and basically is the common understanding between the Product Owner and the Development Team on How deep is the level of details on the item description before the team can start working on it.

If there are more teams than the Definition of Ready (DoR) belongs to all the Product Owners (POs). The DoR has to be inspected and adopted on a regular basis by the Product Owners. It helps to establish and maintain a common understanding of all activities that are necessary for a story to be “ready”.

Role Matrix

At the begining of the project it is good to establish the ‘Definition of Ready’ in agreement with the entire SCRUM TEAM.

DoR

Each item of the backlog will be checked if it respects the ‘Definition of Ready’ before it is taken in Sprint, and the Development Team is the one who approves that the item is written in respect with the ‘Definition of Ready‘.

Example of Definition of Ready:
  1. Every story has to be discussed by Product Owner and the team in the Refinement (Grooming) meeting. All open issues concerning the story have to be resolved.
  2. Every story has to be estimated by the team prior to Sprint Planning.
  3.  No story may exceed the effort that is feasible by the team during one sprint. If the team regards it as larger, it has to be split in several smaller stories by the Product Owner and the team.
  4. Every story has to be prioritised by the Product Owner prior to Sprint Planning.
  5.  Each User Story has to contain at least the following informations
    1.  Motivation – As a <role> I want to <action> so that <value>.
    2. Requirements
    3. Acceptance Criteria
      • Describes how the story has to be presented  (User Acceptance Criteria/Behavioural Test Cases).
      • Basic Criterias should be clarified an written down prior to Sprint Planning
    4. Exclusions
    5.  Mockups
      1. Only if any GUI is affected
    6. External parties / Stakeholders / Business Experts (in case you need to contact someone)
    7. Notes from Grooming
    8. Test hints. Avoid Duplicates in “Requirements” and/or “Acceptance Criteria”

Definition of Done

The Definition of Done applies to all the Items in the Backlog (e.g. User Stories, Tasks, Dev Stories) and basically it is a checklist of “To Dos” applied for each item by the  Development Team in order to make that item potentially shippable/ releasable.

Role Matrix

At the begining of the project it is good to establish the ‘Definition of Done’ in agreement with the entire SCRUM TEAM.

DoD

 

Each item of the backlog will be checked if it respects the ‘Definition of Done’ at the end of the Sprint, and the Product Owner is the one who approves that the item is implemented in respect with the ‘Definition of Done‘.

Example of Definition of Done:

1. Local machine:

  • The issue assigned in  Jira (Ticketing System) is estimated, implemented, works according with the user acceptance criteria, the code passed local testing(responsible: the Assignee)
  • The code is clean, clear, comments; the code is written in compliance with the best practices; code style standards*** are respected (responsible: the Assignee)
  • Quality Checks: The checks in locally-installed Sonar (?|):
    • unit test coverage >= 80|90%
    • branch coverage >= 70|80|90%
    • no new Sonar issues created by commits of the feature
    • no technical debt increase in sonar (by new issues, code duplication, cyclic package dependencies etc.)
      (responsible: the Assignee)
  • Technical Documentation & How To Documents for the users – add it in a accesible place (e.g. Confluence) (if needed) (responsible: the Assignee)
  • The code has been reviewed by at least a peer (responsible: the Development Teams)

2. Test environment:

  • The code is deployed on test (responsible: the Assignee)
  • The Product Owner tests and approves the issue (responsible: the Assignee and Product Owner)

3. Production environment:

  • The code is deployed on production (responsible: the Assignee)
  • The user acceptance criteria are respected and have passed on production (responsible: the Assignee)
  • The issue is marked as DONE in JIRA (responsible: Product Owner)

Additional information
***Code style settings reference: The settings agreed to be used are in this location [add the link here]

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s