Versions Compared

Key

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

The Definition of Done (DoD) represents our team's formal definition of quality for all Product Backlog Items (PBIs). Definition of Done (DoD) is crucial to a highly functioning Agile team. DoD is a checklist/process that the team must perform/complete successfully before declaring the work to be potentially shippable.

The Forminators currently use Jira tickets to visualize, manage, and track story progress from assignment to complete. Final completion is measured as

by working software, committed code in the production instance of Forms.io

by UX design, having human design elements accepted and working

For Proof of Concepts, for Explorative research (Splunking) and for DevOps documentation “How do i?” guidance the definition is a little trickier. It depends. To that end we shall be working to clearly define DoD for our team to adhere to - and to ensure we ‘shift left’ and build quality and pride into our completed work.

This helps our team agree on a standard across our dev community, or UX community. This helps onboard new staff, and also establishes understanding and trust with partners we collaborate with.

...

...

Forminator’s Definition of Done

...

Essentially a pre release checklist of all tasks that the assignee must complete. Meeting the definition of done ensures we meet quality, and that we ensure consistency.

Our in-flight DoD work is currently shown below. Look for updates as our team practices mature

DRAFT: Definition of Done

DoD for Development work:

DONE (shippable)

...

Code produced

...

Code tested

...

Code peer reviewed

...

(DoD)

To ensure Built-In Quality and an Agile approach to Product Development, Forminator’s DoD consist of:

  • Definition of Done (Shippable)

  • Definition of Done (Deployed/Released) || also known as Done Done

Definition of Done (Shippable)

  1. Code/Content produced (In Progress)

  2. Code tested by the developer || Content reviewed and placed in Confluence by the developer (In Progress → Review)

  3. Code/Content peer reviewed (Review | Peer Review)

    1. Code/Content updated and completed based on comments

  4. Code is reviewed by the UX to confirm functional/design requirements are met (Review | UX Review)

    1. Code updated and completed based on comments

  5. Jira ticket includes link to code repository || Jira ticket includes link to the Confluence page for content (Review)

  6. Jira ticket

...

  1. acceptance criteria are met and conclusion

...

  1. is stated/updated in the comment section by tagging Product Owner (Review → Done)

  2. Story accepted by the PO

...

  1. and Ready for

...

DONE (released)

  • Commit request is reviewed by the repository maintainer/gatekeeper

  • Is reviewed by the PO and (dev. peer where required)

  • Commit time is scheduled

  • Changes are implemented and both code repository and Jira ticket comments are finalized

  • Deployed

DoD for Releasable UX design work:

...

Usability review

...

User feedback

...

Create/Update

  1. Pull Request/Deployment (Done)

Definition of Done (Deployed/Released)

  1. Commit for Pull Request/Prod Merge followed the DevOps guideline

  2. Code is updated/finalized

  3. Deployed

Definition of Done (Released: UX/Service Design)

  1. Usability Review/User Feedback

  2. Create/Update Confluence