BizDevOps Starts With Great Requirements
Product delivery leaders are expected to deliver more high-quality features and technology capabilities at a faster pace to stakeholders. In fact, IT satisfaction, one of the primary indicators of IT success, is predominately driven by the delivery team’s ability to deliver projects and work orders effectively (Info-Tech’s Business Vision Survey). BizDevOps is often viewed as way to improve the value IT delivers by instilling a shared collaborative mindset between business and IT.
A successful BizDevOps implementation requires collective ownership and commitment to delivery of requirements across all business and IT roles. Requirements are a team sport and management and stakeholders must be committed to building a culture that fosters this behavior.
What is a requirement?
A requirement sets the expectations and success criteria of a desired function or change of a specific product or service. What is captured in a requirement and who needs to participate in its management are dependent on the type of requirement that will guide decision making and on the methodology (e.g. Agile, Waterfall) that is needed to create, manage, and deliver it. Various artifacts are often used in the facilitation of requirements, such as:
- Epic/business requirement – A statement of a goal or objective that can be estimated and has a defined business value to the organization.
- Feature/functional requirement – Functionality a product needs to provide value to stakeholders.
- Non-functional requirement – Requirement that defines the technical conditions that constrains a solution’s functionality, such as performance, security, and availability.
See our Build a Strong Approach to Business Requirements Gathering blueprint for more information.
What about user stories?
User stories are short descriptions of a desired piece of functionality from the perspective of the customer. They provide just enough information of what the functionality is, who will be using it, and what benefit it will provide to the user. However, user stories are not requirements; they are a placeholder for a conversation (Cockburn). See our Implement Agile Practices That Work blueprint for more information on user stories.
What is the challenge?
Requirements carry a significant weight in product delivery. They lay down the expectations that will define a team’s reputation and their management will define the culture surrounding their delivery. However, siloed requirements management practices and culture damage a team’s confidence to successfully meet these expectations:
- Subject matter experts are not involved in the analysis of a requirement, resulting in poorly understood scope and inaccurate assumptions and estimates.
- The roles who commit to delivery are often not the ones who are delivering the work.
- Stakeholders, decision makers, and product owners may not be disciplined enough to routinely refine their backlogs, roadmaps, and committed plans based on lessons learns and priority changes.
Contrary to a common belief, Agile does not solve these challenges. In fact, Agile methodologies will exacerbate these issues when organizations do not have strong requirements discipline. Therefore, organizations must be prepared to make a significant shift in how requirements are gathered and managed and of the culture built around it.
Focus on requirements culture first
Your requirements management practice must be in a good state before you adopt BizDevOps. This practice encompasses the key capabilities required to understand and confidently commit to a submitted request, which includes, but not limited to:
- Requirements gathering and elicitation
- Intake and backlog management
- Estimation (to be released in the near future)
- Product and delivery road mapping and planning
- Application and product ownership and governance
- Delivery artifact management and metrics
First, build and foster a culture around collaborative and collective ownership of requirements and the delivery artifacts that are created from them (e.g. designs, test cases). Requirements are a team sport. This mindset encourages organizational accountability of delivery value and quality and mitigation of downstream impacts of upstream decisions, rather than resorting to practices that accentuates the challenges of siloed delivery. Ultimately, organizations should be striving to “Be BizDevOps” rather than simply “Doing BizDevOps”.
Next, reinforce your team sport culture by strengthening the governance of your requirements management practices with the right collaboration techniques and a repeatable process focused on collective ownership, quality and business value. Understand a requirement’s actual scope and risks by incorporating and integrating the appropriate roles and teams through facilitated and coached backlog refinement and planning ceremonies/activities.
Then, implement continuous improvement activities to take the lessons learned from recent work to streamline the requirements management process and to deliver value more effectively. Take a hard look at how the delivered product was received and adopted in order to proactively improve product value and quality.
Finally, document and manage your requirements with the right application delivery platform. Unfortunately, many application lifecycle management tools do not have the most appropriate features to manage requirements in a collaborative and holistic way. Some vendors got ahead of this feature gap through acquisitions or expansions of their core platform, such as Jira’s acquisition of AgileCraft. At the moment, organizations wanting to expand their requirements management capabilities looked into specialized tools (e.g. Blueprint, IBM Rational DOORS, Visure, VisionEra) and integrated them into their tooling environment so that all teams can see what is being committed and describe how their work supports the overarching business goal.
Source: Application Lifecycle Management at SoftwareReviews, Accessed March 29, 2020
Our Take
Culture is the fundamental component in developing and managing good requirements in today’s BizDevOps and Agile world. Requirements are a team sport and not something that is thrown over the wall. They are collectively and collaboratively owned and managed by both business and IT and not used to finger point when the requirements and resulting product are wrong. BizDevOps and Agile will not solve many of these challenges but these operational philosophies can guide organizations on how to better think about and treat requirements.
Want to Know More?
Build a Strong Approach to Business Requirements Gathering