Will Scrum continue to grow in popularity? Are user stories the only documentation of requirements in a Scrum environment? What happens to the role of the traditional Business Analyst? These are some of the questions that Dean Leffingwell, author of Agile Software Requirements – Lean Requirements Practices for Teams, Programs, and the Enterprise, will answer in the second part of this two-part interview with site editor Yvette Fran...
SSQ: Your book starts by describing the many software development methodologies and how they have evolved over time. Of the Agile methodologies, you list Scrum as currently the most widely adapted. Do you think Scrum will continue to grow in popularity?
Leffingwell: I do. It's a lightweight framework and it works. It's also supported by a growing community of practitioners, and it is gradually "borging" other Agile practices such as user stories, continuous integration, and TDD. So in a sense it’s evolving and becoming generic Agile, under the label of Scrum, plus "Scrum" and "Sprint" are easy to say and remember. Also certification, while controversial (can one really be a Scrum MASTER after a 2 day course?) adds value to an industry that is always looking for some form of standardization and certification as creature comforts. In addition, at scale, some form of standard practice is required, and I think that will be the one, at least for the next few years. I'm a fan of Scrum (but I’m a fan of XP and others as well).
SSQ: Are user stories the primary documentation for requirements for a Scrum team? What are the important components of a user story?
Leffingwell: Well, there's the basic user voice construct I mentioned above, plus the great alliteration (credited to Ron Jeffries, one of the XP inventors): "Card" (short story written manually on an index card), prevents over specificity in describing backlog items, "Conversation" (as a product owner, I promise to talk to your further about this so you'll understand it better before you cut and test the code), and "Confirmation" (here's the acceptance criteria we will use to evaluate whether or not the code meets the more fully elaborated requirements). Simple, yet elegant and quite powerful.
SSQ: On page 34 of your book you say the roles of a Scrum team include a "Scrum/Agile Master, product owner, and a small team of dedicated developers, testers and (ideally) test automation experts, and maybe a tech lead." What about business analysts? Do they have a role in Scrum?
Leffingwell: Business analysts are still needed for enterprise-class, Agile development. They typically serve in one of three ways 1) as a product owner bound to one or more teams, 2) as the Agile business owner/product manager-equivalent supporting multiple product owners, or 3) as someone who will continue working with the portfolio management function to determine at a higher level, what applications need to be developed, where and what systems are affected. Many of these latter decisions typically operate outside the purview of the Agile teams. If anyone says they don’t need business analysts in Agile, ask them what large enterprise they come from and how else these critical decisions get made.
SSQ: On page 49 of your book, you talk about the conversations between the developer and the product owner to gain more insights into the user story. You say that requirements and design are "inseparable." However, are these detailed requirements documented and reviewed by anyone else?
Leffingwell: Well properly done, they are more thoroughly reviewed than with traditional development. Here's how.
- Each backlog item is initiated by the product owner who has authority and governance over content. They don’t just "appear."
- The story is elaborated by the team, with testers, developers and product owners' perspectives. Detailed acceptance criteria is established before coding.
- The story is implemented and tested in the same time box, and accepted by the product owner when and only when it meets the acceptance criteria and Definition of Done.
- The acceptance criteria, along with hopefully an automated test, persist forever to support regression testing and also serve as a final definitive statement of "what this system actually does," rather than "what we wrote back that we think it does."
- Other key stakeholders, product managers, business owners, marketing, etc. actually "see" the story working in the context of the system at an integrated demo level.
Find out more about how Agile software requirements are managed in part one of this two-part interview with Dean Leffingwell.
Dean Leffingwell is author of the book, 'Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise,' published by Addison-Wesley Professional, ISBN 0321635841, Dec. 2010. For more info please visit www.informit.com/title/0321635841 For a sample chapter, Chp#2, "The Big Picture of Agile Requirements," please visit the publisher site:
(Copyright 2011 Pearson Education, Inc.)