BETA

Skip links

  • Skip to primary navigation
  • Skip to content
  • Skip to footer
Queensland government logo Queensland government logo
Sign in Sign out
Sign in
  • Profile summary
  • Sign out
Department of Education Department of Education Developer Portal
  • Home
  • Tags
  • Chat
  • New
    APIs
  • Help
  • Contact us
  • Dark mode
  • Home
  • Tags
  • Chat
  • New
    APIs
  • Help
  • Contact us
  • My profile
  • Dark mode

Agile Definition of Done - Is it really done?

Jeny Amatya Government
by Jeny Amatya
14 July 2023
Last updated 25 July 2023
Agile
Agile

Introduction

To understanding the ‘Definition of Done’, it is imperative to understand what counts as being “done”. As per Scrum Guide, every sprint is meant to add value to the product by producing usable, shippable deliverables i.e. increments.

As per Scrum Guide, an increment is a concrete stepping stone towards the Product Goal and each increment is additive to all prior increments, thoroughly verified, ensuring that all increments work together.

A Product Backlog item becomes an increment once it meets the Definition of Done.

Definition of Done is a formal description of the state of the increment when it meets the quality measures required for the product.

It is a shared understanding within Scrum team on what it takes to make a PBI releasable. It may vary significantly for every Scrum team. and is used to access when work is complete on the product Increment.

Components of Definition of Done

  • Business or Functional Requirements
  • Quality
  • Non-Functional Requirements

Business or Functional Requirements

  • This component is owned by the Product owner and written in the form of the User Stories and acceptance criteria.

Quality

  • This component is owned by Development team and largely aligned with the coding/technical tools used to build the Product. Examples include
    • Coding standards
    • Unit test coverage
    • Technical Debt
    • No Known Defects

Non-Functional Requirements

  • These are standard characteristics for the Product that may not add direct business value.
    • Performance
    • Security
    • Scalability
    • Compliance/Regulatory etc.
  • They are usually included in Acceptance Criteria or PBI.
Business Requirements Quality Non-Functional Requirements
All acceptance criteria met No build failures Relevant documentation updated
No dependence unattended Functional testing passed Compliance Documents updated
  Integration testing passed Code checked in / merged with branch
  No known defects  
  Compatible with DoE brand  
  No accessibility errors  
  Compatible with mobile devices  

References:

  • Scrum Guide
Powered by Link to AI chat
  • Copyright
  • Disclaimer
  • Privacy
  • Right to information
  • Accessibility
  • Jobs in Queensland Government
  • Other languages

© The State of Queensland (Department of Education) 2025

Queensland Government