Bridging CMMI Requirements Development with Agile Practices: Making “Stuff” Happen
Many Agile teams studying the Requirements Development and Management (RDM) practices in CMMI ask the same question:
“How is any of this agile?”
It’s true—the model doesn’t prescribe specific techniques, and the language can feel dated or overly formal to Agile teams deep in their day-to-day work. But that doesn't mean it’s not compatible. In fact, with the right translation, the CMMI can significantly strengthen how your team approaches requirements—without abandoning Agile values.
When Process Language Gets in the Way
To borrow a line from Gloria Estefan: "The words get in the way."
CMMI’s terminology—think “product and product component requirements”—might work in a classroom or a textbook, but on an Agile team board? Not so much. In practice, I drop the jargon and meet teams where they are.
Instead of rigid terms, I talk about stuff:
The stuff customers say they want (even though it will change).
The stuff we build to try to satisfy them (which also changes).
The stuff we validate, to make sure it's useful—and fundable.
The challenge is aligning that “stuff” with CMMI RDM practices in a way that feels natural, not forced.
A Three-Tiered Requirements Architecture for Agile Teams
To help Agile teams ground their requirements in real, actionable practices, I often recommend a three-tiered architecture plus a cascading “definition of done” that supports clarity, traceability, and better delivery.
Let’s break it down:
Tier 1: The Product Backlog
The backlog captures customer needs in priority order. In CMMI-speak, this aligns with eliciting and developing customer requirements.
Here’s where estimation often comes into play—especially when customers ask questions like “We’re not sure what we want, but how much will it cost?”
For this, Agile teams can use:
Wideband Delphi: A collaborative, experience-based estimation method similar to Agile practices, but focused on effort, not story points.
It's a great middle ground for government or large corporate customers still struggling with the concept of relative sizing.
Tier 2: Epics
Epics represent high-level, user-focused narratives—each potentially encompassing multiple user stories.
While often dismissed as just “big stories,” epics are critical for validation. They help teams and stakeholders clarify scenarios before diving into detailed development. They also uncover defects and assumptions early.
Estimation at this tier shifts toward relative sizing, using tools like:
The Fibonacci Game or the Team Estimation Game
(still collaborative, but faster and more intuitive than formal effort estimates)
Tier 3: User Stories
User stories are the most familiar Agile artifact: focused narratives with clear tasks, completed within a sprint.
CMMI's RMN is especially useful here—it can help uncover hidden or missed requirements that aren't typically found in the backlog.
By the time a story reaches this tier, it’s been validated and refined from initial need → epic → story → task. This clarity makes Planning Poker a natural fit for estimation.
Cascading “Definition of Done”: Validating at Every Level
To bring it all together, I recommend teams define a set of tier-specific validation questions. These help ensure that each requirement, whether a backlog item, epic, or story, meets a minimum threshold of clarity and feasibility.
Some examples:
Is there a clear narrative for the Epic or User Story?
Is the source reliable and validated?
Can all stakeholders understand the request?
Are test cases defined?
Does functionality meet funding and performance requirements?
Have we done this before? Do we have the data?
Is there significant risk we need to manage?
This creates a “gate” at each level of granularity—backlog, epic, story—helping teams spot ambiguity or risk beforedevelopment begins.
Bonus Tip: Use a “Confidence Matrix”
Teams can also implement a lightweight Confidence Matrix:
Mark each validation question as strong or weak.
Tally up a Confidence Score per story.
Use it as a multiplier or input for risk-based estimation.
Over time, teams can even experiment with weighted scoring for more precision.
CMMI Isn’t Anti-Agile—It Makes Agile Better
These are just a few ways to apply CMMI Requirements Development in an Agile context. When teams use CMMI not as a constraint but as a lens for improvement, it helps them level up—starting from the stuff they’re already doing.
So don’t think of RDM as old-school bureaucracy. Think of it as a toolkit to help you:
Clarify what you’re building.
Estimate with more confidence.
Deliver high-quality stories that matter.
Get your requirements architecture in place first—and then go deeper into CMMI. There’s plenty more gold to mine.
Onward!
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.