We’ve studied the practices in Requirements Development, but they don’t seem very “agile.” We know they don’t describe specific techniques we should use, but it’s hard to see how we can align this process area with what we’re doing on our Scrum teams.
JEFF: As Gloria Estefan likes to sing “… the words get in the waaaay …”
When I am working with Scrum teams, I steer clear from terms that are tied to process models or alternative cultures (“hey, what the heck are product-component requirements?”). These terms are all well and good for textbooks and classrooms, but someday somebody is going to get hurt!
I try to adapt my language to local conditions when working with Agile teams, and my favorite word tends to be “stuff.” For instance, the “needs” we elicit from our customers (RD SP1.1) are the collection of stuff that our customers say they want (but will change). Customer Requirements (RD SP1.2) are what we eventually get as we learn more about the stuff they want (but that’ll change too), and then we validate requirements to make sure we can build some cool stuff that they find useful (and are willing to pay for).
To help translate the practices in Requirements Development into “stuff that needs to happen” I usually suggest that agile teams implement two things: a three-tiered architecture that brings clarity to their requirements process and a cascading “definition of done” that helps ensure that the requirements provide a solid foundation for estimation, design, and development.
Note: I will admit that the notion of applying a “definition of done” to the creation of User Stories is not strictly “agile,” but there is no reason we shouldn’t use agile to help improve agile, right?
Tier 1 The Product Backlog represents what the customer has asked for in prioritized order, and the CMMI provides information and guidance for some ways that we might extract and compile the content in RD SP1.1 and SP1.2. Because we are often asked to provide a “rough order of magnitude” estimate for the product backlog (“we don’t know what we want, but how much will it cost?”), we usually use Wide-Band Delphi, a collaborative, experience-based estimation game that is played in three rounds. It is ideal for agile teams because of its similarity to other agile estimation methods, but uses effort, not story points, as its unit of measure. Government and large corporate customers haven’t quite figured out how to deal with the relative sizing of story points yet – but we’re making progress!
Tier 2: Epics draw on the Product Backlog to depict scenarios written from the user perspective, and may represent many User Stories. The CMMI provides guidance in both RD SP1.2 and RD SP2.1 that can help strengthen the narrative so that both the customer and the Scrum team can benefit from increased clarity. Epics are often described as just “big user stories,” but that definition has been driving teams to ignore them altogether in their rush to get to the specific User Stories that they can sink their teeth into. This trend is unfortunate because Epics play an important validation role in uncovering defects in the product backlog long before story development begins. Once Epics are complete, further estimation is needed to prioritize the workload across sprints and releases, so this tier introduces relative sizing models like The Fibonacci Game (“Team Estimation Game”), while leaving the door open for refinement of the effort-based estimate developed at Tier one.
Tier 3: User Stories are user-centric narratives with identified tasks that can be completed within a single sprint. RD SP 2.1 and RD SP 2.2 both provide valuable information for assisting in the development of stronger user stories, while RD SP2.3 can help uncover stories that are not typically represented in the Product Backlog. Because the Scrum team has beaten a direct path from need to epic to user story to task, it now has a thorough understanding of the functionality to be delivered in the next sprint (“value”), so for the third tier, Planning Poker becomes the preferred choice for story point estimation.
So that brings us to the application of a cascading “definition of done” that applies to all three tiers of the architecture. To make this real, I encourage agile teams to collaborate on a set of questions to be asked at each tier as they progress through the process of developing their User Stories. These questions help validate each tier, and assist the team in increasing their knowledge of the functionality being requested. There are no “right” questions here, but REQM SP1.1 and RD SG3 can provide us with some good suggestions to get started. Some of the questions might be:
- Is there an agreed-upon narrative for the Epic or User Story?
- Is the Epic or User Story from the right source?
- Is the Epic or User Story clearly stated so that all stakeholders understand it?
- Is a test case written for the Epic or User Story?
- Will funding levels still support the intended functionality?
- Will the intended functionality meet performance requirements?
- Have we done this before and is historical data available?
- Do we have an experienced team delivering this Epic or User Story?
- Is there substantial risk that needs to be mitigated for this Epic or User Story?
Understanding the status of each question provides Scrum teams with a useful tool to analyze risk for both story comprehension and sprint planning. One lightweight technique to consider is a “Confidence Matrix” that establishes a binary “strong-weak” indicator for each question. This helps teams calculate a Confidence Score and estimation multiplier for each User Story that can serve as one input into understanding the story and identifying defects before they are baked in. As teams iterate through subsequent sprints, and learn to leverage the Confidence Score as a team, they can experiment with weighted scoring if they desire more fidelity.
These are but a few small examples of leveraging the CMMI to improve requirements development in an agile environment. Since CMMI brings you the most value by helping you improve what you already do, agile teams will get even more from the model after deploying a solid requirements architecture that helps them deliver high-quality User Stories in a predictable way. Once they have that, they can look deeper into the CMMI to make it even better. Onward!
© Copyright 2014: Process Assessment, Consulting & Training and Broadsword Solutions
“Just the FAQs” is written/edited by Jeff Dalton and Pat O’Toole. Please contact the authors at pact.otoole@att.net and jeff@broadswordsolutions.com to suggest enhancements to their answers, or to provide an alternative response to the question posed. New questions are also welcomed!
Visit www.broadswordsolutions.com for more information about engineering strategy, performance innovation, software process improvement and running a successful CMMI program.
To download eBooks about CMMI, visit Jeff’s Author Page on Amazon.
No comments:
Post a Comment