We should see the development cycle (sprint) as a sacred place where not everyone can easily get in or out. People must fulfill the qualification (Definition of Ready) before entering it and get out after achieving something (Definition of Done).
While the Definition of Done (DoD) prevents the deployment catastrophic (e.g. unwanted bugs, security vulnerabilities, system down, etc), the Definition of Ready (DoR) keeps the sanity of development. Without the right requirements, we can’t expect good results. With no clear requirement, the delivery never be on time. Unlocked requirements can harm the entire (development) plan.
The article would like to propose a simple checklist as DoR to make sure product requirements/business requests are ready for development. The idea is to make sure all checklist items are there before rather than provide them in the middle of an iteration.
1. Clear Business Context
A clear business context is important for engineers to grasp the problem that needs to be solved and give the right feedback. We don’t expect feedback only on whether the requirement is possible to do or not but it should answers business expectations.
Engineers should not only be builders but also important stakeholders in the problem-solving process.
2. Clear Acceptance Criteria
One of the classic INVEST principles of good product backlog is testable. Acceptance criteria (AC) in PRD (Product Requirement Document) is the right indicator of it.
The QA (Quality Assurance) derives AC for proper test cases and performs the correct test. Without it, everyone may have their own assumption of the output of the product feature.
3. Supporting Documents are attached
Requirements (product functionality) must be equipped by how the user interaction looks like, content (image/wording) that needs put in the application, etc. It is described in supporting documents like Figma for UI mockup or GDoc or anything.
It helps teams to understand and have immediate use. Temporary UI/UX design or dummy content is unhealthy for development.
4. Cross Dependencies are Well-defined and Committed
In the bigger organization and the more complex the system, cross-dependencies are unavoidable. We depend on each other either with internal teams or third parties.
We need to know if the team over there needs to complete first or if the team over here needs to wait for us to finish to continue. We don’t want to get blocked or be a blocker.
5. Constraints are Specified
Sometimes there are constraints that describe a non-functional aspect of the product (some people called it NFR or Non-Functional Requirement). It can be business constraints like budget quota, specific timeline, etc. It also can be tech constraints which are scalability, security, data integrity, and so on.
Since the constraints/NFR is part of the expected result, it must be specified to give hints to the team to not missed it.
6. Explained before the Development
No matter how much detail or clarity your requirement is, there is no guarantee even the best team is able to understand and execute it right. Dropping requirement without a brief is a violation of Agile Principles and a mortal sin of software development.
Summary
- Clear Business Context: Make sure it solves the business problem
- Clear Acceptance Criteria: Make sure it is testable
- Supporting Documents are attached: Make sure the development does not wait for the UI/UX design (or other supporting docs)
- Cross Dependencies are Well-defined and Committed: Make sure no one became a blocker
- Constraints are Specified: Make sure non-functional aspects fulfilled
- Explained before the Development: Make sure the team understands.
