When teams are refining their product backlog, the focus is usually around new features (functional requirements) and sometimes technical debt. Yet when it comes to user frustration and organizational risk, non-functional requirements (NFRs) can be far more important. NFRs define the conditions under which the system must operate, including everything from performance, scalability, and response times to security, disaster recovery, and data retention.Since NFRs aren’t typically referenced in User Stories, business analysts need to ensure they are documented and traced to functional requirements and stories.
In the Modern Requirements blog post “What does your team need to know about Non-Functional Requirements?”, Dane Crawford provides an excellent overview of NFRs, why they are important, and how to categorize and group them. Dane identifies three aspects of NFRs to consider: Operational, Revisional, and Transitional, and how to ensure these requirements are quantitative and measurable. For all analysts, this blog provides good foundational information on NFRs that can improve your practice.
Modern Requirements provides toolchain support for NFRs in their Modern Requirements4DevOps (MR4DevOps) product. With full integration to the Azure DevOps Server, it fills in the requirements management gap found in most delivery management tools. The tool gives teams four ways to manage NFRs in their products and delivery: FAQs, Smart Docs, Reuse, and Trace Analysis. FAQs are a simple way for teams to get started using and question format. Smart Docs provides a more traditional requirements management approach with requirements inserted directly into your Azure DevOps backlog. Finally, MR4DevOps allows teams to build reusable NFR libraries and trace analysis to determine impact from changes.
Regardless of which toolset you choose for NFR management, these are best practices to consider in your selection and setup.
Interested in improving the quality and management of your NFRs and Agile DevOps practices? Consider the following research to support your transformation and maturity.
Improving requirements and quality:
Shifting towards Agile, DevOps, and Product Delivery:
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.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
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.