Defining When a Requirement is Complete
Requirements define the business needs or goals of a given effort and guide the Team on what to build, the customer and user expectations, and provide a way to validate what is built and ensure it satisfies the initial objective.
Before you can call a requirement, or user story, complete, you must first define what you are trying to accomplish and outline the steps necessary to achieve it. Only then, can you successfully identify when a requirement is complete.
The recommendation is that the Scrum Master should lead the Team and Product Owner in establishing and capturing their agreement to a Definition of Ready (DoR) as well as a Definition of Done (DoD).
Definition of Ready (DoR)
In a Scrum or Kanban environment, before a requirement can be assigned to a sprint, Scrum, Inc. says it must be “immediately actionable.” The Team must clearly understand the needs of the user story (i.e. description) from the Product Owner and the actions needed (i.e. acceptance criteria) to successfully call it “done.”
Suggested user story criteria for meeting the Definition of Ready (DoR):
- Approved by the product owner
- Agreement on the requirements
- Story is sufficiently decomposed
- Story has a clear description and acceptance criteria
- Tasks identified
- Card is estimated
Definition of Done (DoD)
Once a requirement is ready, the Team must agree to the steps necessary to accomplish it. Throughout each phase of development (typically represented by a column on a whiteboard or in a tool), the “rules” for passing it along to the next phase should also be clearly defined (e.g. the need for work to be reviewed by a peer prior to being sent to the next phase).
Additionally, a Team may identify other needs based on the type of requirement that should be met, including specific testing needs (i.e. performance testing, penetration testing, etc.), that are necessary to call the user story done.
Suggested user story criteria for meeting the Definition of Done (DoD):
- Updating the status of the card
- Identifying any blockers
- Creating and/or attaching documentation to a story card
- Updated comments or research outcomes are provided
In software development, user story criteria might also include:
- Code is checked in and written according to standard
- Peer review
- Unit testing
- Merging of code
- Integration testing
- Logging of any bug fixes
During UAT or review, user story criteria might include:
- Story card meets acceptance criteria
- Has been reviewed by stakeholders
- Successfully user acceptance tested
Once the requirement, or user story meets the outlined criteria, it is finally considered done when approved by the product owner and accepted by stakeholders.