In the Libraries at UF, we are working to mature our project and project portfolio management processes. One critical part of this is to have a Definition of Done, or the acceptance criteria for how each project/sprint will be evaluated for completion. Having a Definition of Done ensures mutual understanding and agreement for what project completion means, so it defines the acceptance criteria. Related to a Definition of Done (DoD) is the Definition of Ready. The Definition of Ready (DoR) is created prior, with the collaborator/stakeholders, to provide the foundation that allows work to start.
Agility.im explains common elements in a DoR:
-
Actionable – Is the item immediately actionable (doable) by the team? Do the team know what they need to do, and can they do it now? Is the item free from external dependencies?
-
Refined – Has the item been through a process of refinement before sprint planning? Is there a common understanding amongst the team on what the item is and how it will be implemented?
-
Value – What is the business value of the item? What is the value to the end user? Is the value clear to everyone on the team?
-
Estimated – Has the item been estimated by the team? And, is the item agreed to be of a size that the team are comfortable can be completed within a sprint?
-
Acceptance criteria – Has the item got clear acceptance criteria?
-
Demo – Do the team understand how they might demo the item or discuss it in the sprint review once complete?
Similarly, “Definition of Ready (DoR) vs. Definition of Done (DoD)” on LinkedIn provides a sample DoR:
User Story is clear
User Story is testable
User Story is feasible
User Story defined
User Story Acceptance Criteria defined
User Story dependencies identified
User Story sized by Development Team
Scrum Team accepts User Experience 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
In Library Technology Services, we’re working to mature our project/process management work. And, we fully understand that ideas like Definitions of Done and Definitions of Ready are meant to enable (and not gatekeep) on work moving successfully. To get us closer to DoR, we’re in the process of adding in a step for a case briefing for new projects, where we ask basics on the reason for a project, sponsor, assessment, risks, expected outcomes and criteria for measuring success. We have a lot of this for specific projects at a high level (via grants with project plans, project charters, etc.), and then often for specific tasks/work, but this has not be implemented as foundational support overall. We need this. Right now, we do the work with fewer explicit supports, meaning the work is often in-head instead of documented-communicable. The more limited manner was okay when still clearing very old and less complex technical debt, where many things were readily known. For both more complex or newer projects, we require additional supports to operate. Importantly, additional supports will better position our collaborators as fully engaged partners, to help explain/demonstrate the work required for success, for optimal understanding and engagement.