Comprehensive software reviews to make better IT decisions
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
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?
Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure dollars on the table.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.
Stakeholders expect the speed and responsiveness of product delivery does not come at the expense of quality. QA tools offer retailers the ability to continuously ensure both business and technical quality standards are upheld, but these tools should not be viewed as a silver bullet.
No matter how good your product roadmap and backlog are, they are only as good as your audience’s ability to understand your vision and priority.
The scrum master is like the conductor of an orchestra, ensuring that every piece fits together at the right time to create something greater than the sum of the parts. You don’t have to know how to play each instrument, but you do have to understand what each part contributes to the overall masterpiece.
Tools are important to product teams, but only when they support solid people and processes.
Aha! introduces scenario planning to give product owners the ability to create and compare multiple release approaches based on team capacity and backlog priority.