Getting “just enough” information about desired behavior of a new feature without creeping into “Big Up Front Design”...
or “mini-waterfall” is a balancing act for many Agile practitioners. Mary Gorman, along with her colleague Ellen Gottesdiener, have developed lightweight approaches to eliciting specifications in Agile projects. I asked Mary about the techniques they’ll be sharing at Agile 2011.
Lisa Crispin: You have an Agile 2011 session about using “structured conversations” to deliver value. Can you give us a quick overview of what defines a “structured conversation”?
Mary Gorman: While many Agile teams use conversations to convey information about a product, not everyone is a good conversationalist! Kidding aside, Ellen Gottesdiener and I have crafted a light weight approach that enables stakeholders to quickly yet holistically explore and evaluate options for building a software product. The structured conversation asks targeted questions about seven product dimensions resulting in identifying the most valuable requirements options for the next delivery cycle. We’ve found it to be an inclusive way to jointly engage business and technology folks. It levels the playing field, engages all stakeholders, enables defining a shared understanding of product needs, and facilitates mutual learning.
Crispin: Will participants in your tutorial actually get to practice structured conversations?
Gorman: Absolutely! More than 75% of the tutorial will be experiential. Ellen and I will facilitate a group simulation of the structured conversation and then folks will break into teams to practice ‘conversing’ using the seven product dimensions. And Lisa, I’m sure you’ll be happy to know that they will validate their conversations with acceptance criteria.
Crispin: You have a session on the Agile 2011 Testing Stage called “Business Rules Essentials for Quality Software.” You’re an expert in business analysis. How much overlap do you see in the BA and tester roles?
Gorman: I see lots of synergy and opportunity for the two disciplines to collaborate. For example, user stories, personas, data details, business rules and examples are invaluable for understanding the business needs from both the analysis and testing perspectives. Likewise for process maps and state diagrams. They provide a rich context to frame elicitation and enable validation and help us consider dependencies and related pre- and post-conditions. When I work with teams, I also include another collaborator-- the UX folks. Their work is tightly integral to analysis and testing. Getting those three disciplines to work together, in concert, can be a powerful, efficient boost to the team.
Crispin: The session description for your business rules session mentions effective estimating. What do you see as the purpose for estimating in Agile projects? Estimates are really guesses; can they actually provide any value?
Gorman: Lisa, these questions go beyond the scope of my presentations, but are interesting questions, so I’ll comment briefly.
Our business partners need estimates to balance cost with benefits and decide what to build, and when. While estimates are guesses, disciplined Agile teams get better and better at estimates, enabling our business partners to make better decisions. The more you understand about the requirements, the better the team can estimate.
The act of estimating is also a form of testing: it is testing the delivery team’s understanding of the requirements. Estimating tests our understanding of requirements. At the same time, effective yet lean requirements analysis increases the quality of our estimates.
Crispin: My team often struggles to get our product owner and other stakeholders to define business rules for user stories. What’s the secret to getting this information in a timely manner?
Gorman: Going back to the structured conversation-- one of the seven dimensions is “control.” It encompasses business policies as well as detailed business rules. We coach our teams to explore the business rules, as part of their conversation. So when they identify high valued user roles, actions and data they also explore the associated business rules and evaluate them accordingly. Following this conversation approach, we also compress and isolate the business rules we need to explore. Identifying the rules helps to understand the user stories’ complexity, and influences the estimates. Then, those business rules are fully detailed as the team defines examples-- acceptance tests-- and builds the product.
Crispin: You are working on a book with Ellen Gottesdiener. Please tell us about it. When will it be published?
Gorman: There are numerous excellent books about Agile, but few specifically about Agile requirements and how to collaborate to build a shared understanding of product needs in an efficient and effective manner. We’re hoping to fill that gap. We are writing about the partnership that’s needed to explore and evaluate requirements, regardless of role, how the partners collaborate using structured conversation techniques. There are lightweight steps and integrated examples that the readers can easily reference again and again. Our goal is to deliver an “Agile book”-- a just-enough, well designed, high-value, practical guide that serves the entire team. We’ve had several major reviews and are talking with a number of publishers, so stay tuned for a launch date.