We’ve all heard about the importance of developing a shared “Definition of Done” (DoD) wherein the completion of a Salesforce feature can be validated for deployment to Production. But what about making sure that the feature meets the actual business requirement?
In this article, we’ll borrow from Agile methodology to introduce a “Definition of Ready” (DoR) – a four-part framework to help Salesforce teams ensure that their requirements are ready to be developed and bring value to the business. Using this guide, we’ll unpack how to shift fuzzy user needs into clean, development-ready requirements.
What Is a Good Requirement?
User requests are not the same as requirements. Requests often come in the form of directives – they often imply technical solutions instead of true functional needs, they may be positioned as more critical than they are, and their value to the business has not yet been validated. Good requirements, however, carry certain features:
- Follow a consistent, descriptive structure (i.e. user story “As a ___, I want to ___, so that ___” format).
- Exhibit utility and reliability to produce business value.
- Have contextualized and testable User Acceptance Criteria.
Sound requirements are informed by an intentional process of discovery that is informed by an understanding of the business that is both broad and deep. Discovery is a journey of definition wherein functional and technical requirements represent the lowest, most granular level of the discovery process.
Definition of Ready: A Four-Part Framework
Moving from fuzzy user needs to high-quality requirements is both an art and a science. By employing a replicable Definition of Ready against which to scrutinize requirements, business analysts can support the generation of high-quality development-ready requirements.
My simple, four-part Definition of Ready includes ensuring that requirements are:
- Defined
- Discrete
- Valuable
- Mature
In this guide, we’ll explore each of these dimensions and provide a talk-track to help business analysts interrogate user needs and improve requirement quality by ensuring requirements meet the criteria for each of these sequential parts. Scroll to the bottom of the article for a downloadable cheatsheet.
Defined
Requirements definition is the first and most crucial step to unlocking a requirement that is ready for development. A requirement that is ready should demonstrate a clear:
- Persona(s) that will be serviced by the associated functionality.
- Action to be done.
- Rationale for why the action needs to happen.
The requirement should be formatted in an acceptable and universal structure (i.e. User Story format) and be complete with User Acceptance Criteria and assumptions. The requirement should also demonstrate clear parameters, including:
- Whether the requirement is technical or functional.
- Any security and sharing requirements.
- Whether the requirement represents a new issue, a change request, or a bug.
If your team is struggling with defining their requirements, consider asking questions like:
- Is this something a user does/needs, or is this a technical requirement (i.e. performance-related)?
- Is this feature brand new, does it adapt an existing way of working, or is it resolving an issue?
- Who does this feature support?
- What do you need to do? Or, what question are you trying to answer with your data?
- Why do you need this feature?
- Where does the data come from, and how will it enter the system?
- Should the data be archived or deleted within any timeframe?
- Who should or shouldn’t be able to access this feature/data?
A defined requirement has clear parameters that aid both technical and business stakeholders in understanding the form and function of the need.
Discrete
A discrete requirement is unique and independent. It is able to be differentiated from other requirements and serves a distinguishable purpose. Ensuring a requirement is discrete enables the team to identify its relationship to other discrete requirements, so that the requirement can:
- Be prioritized or triaged against other requirements.
- Be related to other requirements.
- Have its technical and functional dependencies identified.
- Be estimated.
Surfacing a discrete requirement can be tricky when users aren’t perfectly clear on their needs. To help massage a fuzzy need into a discrete requirement, try asking:
- What is the criticality of this requirement?
- Does this feature enhance or extend any existing or in-progress features/requirements?
- What business assumptions underlie this requirement?
- What technical assumptions underlie this requirement?
- What are the related/dependent business processes?
Ensuring a requirement is discrete allows it to be contextualized in the corpus of requirements, giving it an identifiable place in the software development lifecycle.
Valuable
The value of each new requirement should be interrogated before implementation. Understanding a requirement’s value means understanding the “why” that sits behind it. By surfacing the actual problem or pain point, architects can deliver solutions that support a positive user experience. A valuable requirement unlocks new business value by:
- Enabling users to do something they couldn’t do before.
- Enabling users to do something they are currently doing more efficiently or effectively.
The implementation of a new feature in Salesforce should be a good investment for the business. Consider the opportunity cost of the requirement – does the cost of not solving for the requirement outweigh the cost to implement it?
When querying the value of a requirement, consider asking the following questions:
- What is the demonstrable business need that this feature would support?
- How does this feature save time or add value?
- How many users or business units will this feature support?
- Would this feature hinder the work of any others?
- What would happen if we didn’t implement this feature?
A valuable requirement should save users time, make their lives easier, or empower them to do something new that they weren’t able to before.
Mature
Sometimes even requirements that are well-defined, discrete, and valuable aren’t ready to be implemented. When forming and triaging new requirements, it is critical to assess if the requirement is mature – that it represents a validated functional need that is ready to be implemented and adopted by the business. A mature requirement:
- Represents a demonstrable business need.
- Represents a stable business need.
- Can be implemented to its required specifications by the available team.
- Can be adopted by the users.
Businesses change over time, and so do requirements. When considering whether or not to begin development on a requirement, query how changeable the underlying business processes are. If the business is in a state of flux, waiting may be a better option. To query the stability of a requirement, consider asking:
- How long has the team been experiencing this need?
- Does this requirement represent an existing or prospective/potential need?
- Can users clearly explain or document the associated business logic?
- Will the underlying business process change in the near future? If so, how?
Effective software development isn’t just about shipping features – it’s about ensuring a positive user experience. A mature requirement is also one that is ready to be adopted by the business. To better understand any potential change management issues, consider asking your team:
- Does the internal team have the necessary skills to implement this feature to a high degree of quality, and in a reasonable amount of time?
- Do users have the capacity to learn and use this feature as it was intended?
- What training may need to take place to support adoption, and when do users have the capacity to undertake this?
Effective technical project management means being able to ship just-in-time features that add value to mature business processes in a way that users can digest. Before considering a new requirement “ready”, be sure that it supports a reliable business need, and that change management practices are in place to support adoption.
Download the Cheatsheet
Need a quick and easy way to share this Definition of Ready with your team?
Final Thoughts
Developing a Definition of Ready for your team’s requirements, even if it differs from the method above, is a crucial step in ensuring that your development team is only taking on high-quality requirements that are ready to add demonstrable value to the business.
