As readers of this blog know, I’ve been using my previous book, Scaling Software Agility: Best Practices for Large Enterprises, as a reference (along with many others) to help software enterprises become more agile. In the course of many engagements, a recurring theme keeps popping up, “How do we handle requirements at scale in an agile environment?” I’ve been addressing some of the answers in various blog posts and whitepapers (see Agile Requirements category and A Lean and Scalable Requirements Model for Agile Enterprises.) Also, I’ve written fairly extensively on the requirements topic in the past, in Managing Software Requirements: First and Second Editions, from Addison-Wesley.
In the last few years, I’ve learned a lot of practical approaches to managing requirements for systems, both small and large, in an agile manner. In addition, other agilists have been thinking about this problem as well and have made substantial contributions to the art. Although I tried to duck the “write another book” issue”, it just wouldn’t go away, so in a moment of temporary insanity, I committed to writing it. The book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise has just been published by Addison-Wesley.
Here’s the back cover introductory text:
“We need better approaches to understanding and managing software requirements, and Dean provides them in this book. He draws ideas from three very useful intellectual pools: classical management practices, Agile methods, and lean product development. By combining the strengths of these three approaches, he has produced something that works better than any one in isolation.”
—From the Foreword by Don Reinertsen, President of Reinertsen & Associates; author of Managing the Design Factory; and leading expert on rapid product development
Effective requirements discovery and analysis is a critical best practice for serious application development. Until now, however, requirements and Agile methods have rarely coexisted peacefully. For many enterprises considering Agile approaches, the absence of effective and scalable Agile requirements processes has been a showstopper for agile adoption. In Agile Software Requirements, Dean Leffingwell shows exactly how to create effective requirements in Agile environments.
- Part I presents the “big picture” of Agile requirements in the enterprise, and describes an overall process model for Agile requirements at the project team, program, and portfolio levels
- Part II describes a simple and lightweight, yet comprehensive model that Agile project teams can use to manage requirements
- Part III shows how to develop Agile requirements for complex systems that require the cooperation of multiple teams
- Part IV guides enterprises in developing Agile requirements for ever-larger “systems of systems,” application suites, and product portfolios
This book will help you leverage the benefits of Agile without sacrificing the value of effective requirements discovery and analysis. You’ll find proven solutions you can apply right now–whether you’re a software developer or tester, executive, project/program manager, architect, or team leader.
And here’s an overview of the book, taken from the “Front Matter”.
Scaling Software Agility 
On page 11-4, footnote 3, you cite Pragmatic Marketing as Pragmatic Marketing Institute. The name is Pragmatic Marketing, Inc and website is http://www.pragmaticmarketing.com. If you’d like, you are welcome to reference http://www.pragmaticmarketing.com/pdf/Living_in_an_Agile_World.pdf which contains a view of the product manager vs product owner roles.
Your book is looking good! Keep it up!
Hi Dean,
Haven’t checked the draft yet, but have been reading your posts about scaling agile and requirements handling to the enterprise.
Very interesting so far, but I lack one piece of advise: how to handle high inflow of requirements and prioritization.
Today’s enterprises are flooded with a lot of incoming requirements, from different stakeholders who claim the requirements are very high prio for them. These requirements also come in all sorts and shapes: very detailed, high level, etc (i.e. they could be either epics, features or user stories as per your nomenclature).
The model you proposed in “A Lean and Scalable Requirements Information Model for the Agile Enterprise” does take care of the hierarchy of different requirements. But without practical advice on how to place requirements in such levels, and without advice on how you can prioritize them (e.g. for release or iteration planning), the model will not reach its full potential.
Some questions for brainstorming:
– If you have epics A, B, and C (in this order of priority), and features A1, A2, B1, B2, and C1, C2 (children of their respective epics). Now you want to plan a release, so you look at what features it will have. How do you work with feature priority in relation to epic priority? Will all features of the C epic have lower prio than the B epic, and B epic’s features have lower prio than A epic’s features? Or will you have a cross-epic feature prioritization? If that would be the case, why would you have prios in epic level in the first place?
This could get even more confusing when you bring user stories to the scene. Imagine that you got a new user story from some stakeholder, which does prove to be very important. But now you can’t find a related feature or epic where that user story would fit because you overlooked that area when doing your release planning. Two options: maybe you create the missing feature/epic and rework your prio on the higher level, maybe you just squeeze in the user story into a sprint, disregarding the high level planning. Or how to do it? I see this type of “side requirements” appearing all the time, and I couldn’t yet find a good way to handle them when they are not related to current top prio features for a release.
And add to all these different stakeholders, with different levels of importance, and the problem will get even uglier.
Kind of hard to describe the problem here, but if you could address the problem of prioritizing requirements when you work with multiple levels like epic/feature/user story, that would be much appreciated.
Otherwise you end up with a nice looking tree of requirements that won’t help you in planning.
Cheers,
Andrigo
Andrigo,
The purpose of this model is to allow an enterprise a basic mechanism to reason about differing kinds of things at differing, and appropriate, levels of abstraction. As an artifact model, it does’t tell you how to prioritize one epic from another, but it’s an improvement over attempting to prioritize unlike things, for example an important epics versus an important story. In order for a software process model to be complete, you need three things, 1) the artifact set, 2) the roles and 3) the activities whereby, for example, artifacts are transitioned from one state to another. That’s a much broader topic than the requirements hierarchy (just the artifact set) and will be the subject of a big portion of the upcoming book. What I can say is this: all priorities are local. What this means is at the portfolio level, teams need economic justification for prioritizing one epic over another. At the release level, it’s one feature vs another, at the sprint level it’s one story over another. For the longer answer, you’ll need to read the book, but to do that, I have to finish writing it first.
Hi Dean,
When are you anticipating that your new book will be published?
Thank you!
Kelly,
Probably midsummer to early fall. Let me know if there are pieces you need in advance.
Dean
Interesting. I’m working in a team of c. 200 folks split into 3/4 portfolio products (although they’re not yet recognised as such). Our biggest challenge at the moment is moving from big-bang releases to continuous delivery.
Your picture in ch.1 implies NFRs are impediments – items that a team has to conform to for a release to be acceptable. Our approach now is to make NFRs features in their own right and plan for them accordingly.
Do you have any comments on how this works in practice?
Jeremy,
Well, NFRs are certainly things you have to design to, especially for larger systems, though I don’t think I ever implied they were impediments. (other than impediments to shipment if you missed one!).
There’s a number of ways to handle them (store them , categorize them, find them when you need them), which I cover in Chapter 17 (special agile project folder, RUP like supplemental spec, part of the vision document) of the upcoming book. Many NFRS could be treated as “features” (ex: handle 10,000 users without performance degradation”, others far less “feature like” (example: don’t use any open source without legal approval).
It’s just most important to know that they exist, especially for systems of scale, and the teams treat their discovery and management as critically as they do functional items. For if it isn’t secure, reliable, available or whatever, not much good will come from the program.
Dean, I started reading your book about a week ago. I’m really enjoying it. I have a question for you. You mention prototyping in the book as a way to gather additional inputs/clarification possibly upfront, or for spikes. Have you seen prototyping used to define user stories across the board prior to forming backlogs? Prototyping may not be the right word, I’m thinking more about Software Visualization. Have you come across visualization and it’s impacts on Agile? I’m seeing this play out on several fronts and developers seem to push back hard on this. My guess is it’s because the visualization is not broken down into digestible stories. What are your thoughts on this?
Thanks
Jason
Sorry Jason, no real experience to draw on.
It’s an interesting topic. We’ve been visualizing software since 2005. It’s a far step away from traditional requirements definition, but is starting to get traction. Let me know if you’re interested in learning more. I feel it has a place in User Acceptance testing within Agile. Visualize the user story and perform testing prior to coding. The process would be: Define | Test | Build | Test
My argument is that this can reduce rework significantly buy reducing the number of corrective sprints need on a project. It would allow Product Owners to better validate the story prior to any coding.