Requirements Maturation Flow: Shared Understanding, Bespoke Done, Ready
TL;DR
- Premature implementation before achieving explicit readiness, driven by a lack of shared understanding and clear definitions of done/ready, causes significant rework, delays, and defects, ultimately leading to project failure.
- Requirements Maturation Flow (RMF) introduces explicit readiness work and gating to ensure understanding and validation before implementation, dramatically improving progress toward goals and reducing engineering team stress.
- Treating each work item as a unique case, with bespoke definitions of done and ready, provides clarity for both development teams and product owners, enabling accurate estimation and successful delivery.
- Shared understanding, as the first pillar of RMF, requires dedicated time for teams and stakeholders to negotiate scope and solution details, preventing the delivery of incorrect or irrelevant functionality.
- A bespoke Definition of Done, tailored to each work item, ensures all necessary criteria are met, fostering trust and accelerating delivery by providing a precise target for completion.
- The Definition of Ready establishes product exit criteria, ensuring that all necessary artifacts, such as requirements, specifications, and designs, are provided to the team before implementation begins.
- Implementing RMF, even partially by focusing solely on shared understanding, can yield significant benefits by creating explicit work items for readiness activities and reserving necessary capacity.
Deep Dive
Software projects frequently fail not due to flawed execution methodologies like Agile, but because implementation begins prematurely, before teams are properly prepared. This premature start leads to rework, delays, defects, and mounting technical debt. The Requirements Maturation Flow (RMF) framework addresses this by introducing explicit readiness work and gating, ensuring teams have a shared understanding and well-defined criteria before committing to implementation. This structured approach dramatically improves progress toward actual goals and reduces stress on engineering teams.
The core of RMF lies in its three foundational pillars, which can be implemented independently or in conjunction, offering value even when adopted piecemeal. These pillars are: Shared Understanding, Bespoke Definition of Done, and Bespoke Definition of Ready.
Shared Understanding moves beyond typical backlog refinement meetings, which often lack the depth needed to truly prepare individual work items. Instead, RMF advocates for dedicated, time-boxed "readiness work" to ensure thorough comprehension of requirements and scope. This involves reserving specific capacity within a sprint for activities like detailed discussions with stakeholders, clarifying ambiguities, and documenting insights. The goal is to reach a point where the team and stakeholders have an identical, confident understanding of the desired outcome, evidenced by the team's willingness to be held accountable for delivering precisely that. This process helps mitigate situations where stakeholders claim implicit requirements were missed, as the shared understanding phase explicitly clarifies scope and expectations.
The Bespoke Definition of Done (DoD) tailors completion criteria to each specific work item, rather than relying on a generic, often forgotten, organizational standard. This bespoke DoD is co-created and approved by all relevant parties, including product owners and engineers. This shared agreement ensures that the definition accurately reflects what "done" means for that particular task, encompassing not only coding standards and testing but also specific requirements like architectural reviews, user acceptance, or legal review. This process creates a clear contract: when all criteria in the bespoke DoD are met, the work item is considered complete, and responsibility transfers back to the product owner. This shared accountability prevents product owners from introducing new requirements late in the cycle and compels teams to ensure all agreed-upon criteria are met, fostering trust and accelerating delivery.
Similarly, a Bespoke Definition of Ready (DoR) establishes clear criteria for when a work item is ready for implementation. This typically includes two categories: product exit criteria and team readiness criteria. Product exit criteria ensure that all necessary documentation, specifications (e.g., behavioral specifications for BDD), UI designs, and any other required information are provided to the team. Team readiness criteria ensure the team has the capacity and capability to undertake the work, potentially including necessary refactoring or research into the existing codebase to support the new functionality. By explicitly defining what constitutes "ready," this pillar prevents teams from starting work on underspecified or technically unsupportable items, thereby avoiding rework and delays.
Implementing RMF, particularly the bespoke DoD and DoR, ensures that work items are not treated uniformly. Instead, each is analyzed for its unique complexity and requirements, leading to more accurate estimates and a higher likelihood of successful, on-time delivery. This structured approach to readiness is crucial for mitigating common software project failures, even within highly capable and motivated teams.
Action Items
- Audit authentication flow: Check for three vulnerability classes (SQL injection, XSS, CSRF) across 10 endpoints.
- Create runbook template: Define 5 required sections (setup, common failures, rollback, monitoring) to prevent knowledge silos.
- Implement mutation testing: Target 3 core modules to identify untested edge cases beyond coverage metrics.
- Profile build pipeline: Identify 5 slowest steps and establish 10-minute CI target to maintain fast feedback.
- Draft shared understanding checklist: Define 5 key questions to ensure alignment on requirements before implementation.
Key Quotes
"What I saw was a pattern of behavior or a pattern of practice that led to the concept of readiness. I would say probably the earliest example of this in a scrum or agile software development setting was when I was a technical product manager at Infospace and we had to develop lots of different internal solutions for the loading of data, the management of data as well as the consumption of data in the organization's massive databases that we had."
Max Guernsey III describes the origin of the readiness concept, stemming from observed patterns in agile development. He highlights early experiences in a technical product manager role where traditional Scrum practices led to struggles in delivering satisfactory solutions. This realization prompted a need for more thorough understanding and stakeholder discussions before committing to implementation.
"And so pretty quickly I realized that we were struggling in the classic application of scrum and this user story format that doesn't really have all the details in it typically, you know the 'as a, I want, so that' format. So to combat that, what we would do as a team is in preparation for an upcoming sprint, I would pull the team as well as other teams that we might be working with or be depending on for something that we were going to have to consume that they had to create, as well as my stakeholders."
Guernsey explains the limitations of the standard user story format in Scrum, which often lacks sufficient detail. To address this, he initiated a practice of bringing together the development team, dependent teams, and stakeholders for dedicated preparation sessions before sprints. This proactive approach aimed to foster a deeper understanding of the problems to be solved and the expectations involved.
"And so then we go and we start to investigate the veracity of these claims and here's the weird part, they were all right. Like, there's one exception, there's one guy in product who was pretty solid. He knows who he is. I'm not going to name him either, but they all had problems with their ability to perform the function of their job."
Luniel de Beer recounts an experience at a bank where multiple individuals and teams blamed each other for project failures. Upon investigation, de Beer found that these claims of dysfunction were largely accurate, with developers producing redundant code and product teams lacking domain knowledge. This situation highlighted systemic issues rather than isolated incidents.
"And so then we go and we start to investigate the veracity of these claims and here's the weird part, they were all right. Like, there's one exception, there's one guy in product who was pretty solid. He knows who he is. I'm not going to name him either, but they all had problems with their ability to perform the function of their job."
De Beer describes the discovery that, despite finger-pointing, the issues cited by different groups (developers, product, leadership) were indeed real. This indicated widespread problems across various roles within the organization, contributing to the overall failure to deliver.
"And so that started making us dig into, as a first point, understanding and then once it was clear that the team wasn't understanding, it kind of like was this, we needed a way to make it happen. And that kind of was like this wedge driven into their process where we needed to put something in their process that forced understanding before they actually started implementing."
Guernsey explains how the observation of teams building entirely incorrect solutions, not just misinterpretations, led to the realization that a mechanism was needed to enforce understanding before implementation. This insight became the driving force behind developing a process that would act as a "wedge" to ensure comprehension.
"So the way that you know is we have a kind of a transfer of responsibility mechanism. We have a model for that. It's like a big thing that we can install in big organizations, but we kind of created a little slice of it, a sliced-down version of it just for teams to use in RMF. And so you know that you have shared understanding when you meet the standard that the team is willing to put themselves completely in the product or stakeholders' hands, like be at their mercy for when the work item closes."
De Beer explains how to determine if shared understanding has been achieved. He describes a mechanism involving a transfer of responsibility, where the team is willing to be held accountable by the product owner or stakeholders for the outcome of their work. This willingness to be "at their mercy" signifies a high level of confidence in their comprehension of the requirements.
"So, in addition to helping us solve a dysfunctional environment where people are not taking responsibility or being lazy or they have poor practices or something like that, it also helps in scenarios where teams are truly highly successful and highly capable, highly motivated, but just want to make sure that the right thing gets done."
De Beer emphasizes that the Requirements Maturation Flow (RMF) is beneficial not only for teams struggling with dysfunction but also for highly capable and motivated teams. He suggests that RMF provides essential guardrails and clarity, ensuring that even successful teams are focused on delivering the correct and most valuable outcomes.
"So as the product owner, I want to make sure that I am giving the team the best chance of succeeding in delivering this thing that I'm asking them to deliver. So having clarity on the definition of done, what it actually means to be done, is not just important for the team, it's important for me because I need to make sure that the team has this clear understanding of what done actually means, but it also means I have to have a clear understanding of what done means."
De Beer highlights the product owner's perspective on the importance of a clear Definition of Done (DoD). He explains that for a product owner, a well-defined DoD is crucial for enabling the team to succeed and for ensuring that the delivered work aligns with expectations. It also requires the product owner to have a thorough understanding of what "done" entails.
Resources
External Resources
Books
- "Ready: Why Most Software Projects Fail and How to Fix It" by Max Guernsey III and Luniel de Beer - Mentioned as the co-authored book by the guests.
Articles & Papers
- "Making Scrum Work" (Software Engineering Radio) - Mentioned as a related episode discussing software methodologies.
- "Patterns and Anti-patterns for Successful Software Delivery in Enterprises" (Software Engineering Radio) - Mentioned as a related episode discussing software methodologies.
- "Basecamp's Software Development Process" (Software Engineering Radio) - Mentioned as a related episode discussing software methodologies.
People
- Max Guernsey III - Software architect, educator, and co-founder of Prodycore.
- Luniel de Beer - Creator of the Requirements Maturation Flow and Prodycore's Capability Management System.
- Brijesh Amanat - Host of Software Engineering Radio.
- Ryan Ripley - Guest on a previous Software Engineering Radio episode.
- John Smart - Guest on a previous Software Engineering Radio episode.
- Ryan Singer - Guest on a previous Software Engineering Radio episode.
- Kent Beck - Mentioned in relation to the concept of "making the change easy."
Organizations & Institutions
- Software Engineering Radio - Podcast for professional developers.
- IEEE Computer Society - Sponsor of Software Engineering Radio.
- IEEE Software Magazine - Sponsor of Software Engineering Radio.
- Prodygycore - Consultancy dedicated to fixing delivery failures.
Other Resources
- Requirements Maturation Flow (RMF) - A practical system for fixing gaps between product intent and engineering execution.
- Capability Management System - A traceable and scalable approach to modeling product capabilities.
- Scrum - A framework for managing product development.
- User Stories - A format for user stories in Scrum.
- Behavior Driven Development (BDD) - A software development process.
- Definition of Done - Criteria for completing a work item.
- Definition of Ready - Criteria for a work item to be ready for implementation.
- Product Backlog Items (PBIs) - Individual items in a product backlog.
- Planning Poker - A method for estimating story points.
- Cargo Cult - Mentioned as a concept to describe adopted practices without understanding their underlying principles.