Agile Software Requirements

 


In my opinion, there is no book out there that more artfully addresses the specific needs of agile teams, programs, and portfolios all in one. I believe this book is an organizational necessity for any enterprise.
Sarah Edrie , Director of Quality Engineering, Harvard Business School



Foreword by
Don Reinertsen


Agile Software Development Series
Hardcover:
560 pages
Publisher:
Addison-Wesley
Professional
 
Publication Date:
January 6, 2011
 
ISBN-10:
0321635841
ISBN-13:
978-0321635846

 


Table of Contents

Acknowledgments

Foreword by Don Reinertsen

How to Read
This Book

Preface

“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.”
Don Reinertsen
President of Reinertsen & Associates, Author of “Managing the Design Factory,” and Leading Expert on Rapid Product Development


About Agile Software Requirements

Effective requirement discovery and analysis is a critical 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.

—From the Back Cover


Praise for Agile Software Requirements

Agile Software Requirements and Mr. Leffingwell’s teachings have been very influential and inspiring to our organization. They have allowed us to make critical cultural changes to the way we approach software development by following the framework he’s outlined here. It has been an extraordinary experience.”
Chris Chapman , Software Development Manager, Discount Tire

“This book supplies empirical wisdom connected with strong and very well-structured theory of succeeding with software projects of different scales. People new to agile, practitioners, or accomplished agilists–we all were waiting for such a book.”
Oleksandr (Alex) Yakyma , Agile Consultant, enter-Agile.com

“This book presents practical and proven agile approaches for managing software requirements for a team, collaborating teams of teams, and all across the enterprise. However, this is not only a great book on agile requirements engineering; rather, Leffingwell describes the bigger picture of how the enterprise can achieve the benefits of business agility by implementing lean product development flow. His ‘Big Picture’ of agile requirements is an excellent reference for any organization pursuing an intrinsically lean software development operational mode. Best of all, we’ve applied many of these principles and practices at Nokia (and even helped create some of them), and therefore we know they work.
Juha-Markus Aalto , Agile Change Program Manager, Nokia Corporation

“This pragmatic, easy-to-understand, yet thought-provoking book provides a hands-on guide to addressing a key problem that enterprises face: How to make requirements practices work effectively in large-scale agile environments. Dean Leffingwell’s focus on lean principles is refreshing and much needed!”
Per Kroll , author, and Chief Architect for Measured Improvements, IBM

“Agile programming is a fluid development environment. This book serves as a good starting point for learning.”
Brad Jackson , SAS Institute Inc.

“Dean Leffingwell captures the essence of agile in its entirety, all the way from the discrete user story in the ‘trenches’ to complex software portfolios at the enterprise level. The narrative balances software engineering theory with pragmatic implementation aspects in an easy-to-understand manner. It is a book that demands to be read in a single sitting.”
Israel Gat , theAgileexecutive.com , @Agile_exec on Twitter

“An incredibly complete, clear, concise, and pragmatic reference for agile software development. Much more than mere guidelines for creating requirements, building teams, and managing projects, this reference work belongs on the bookshelf of anyone and everyone involved with not only agile processes but software development in general.”
R.L. Bogetti , Lead System Designer, Baxter Healthcare

“This book covers software requirements from the team level to program and portfolio levels, including the architecture management and a consistent framework for the whole enterprise. We have practiced the multi-team release planning and the enterprise-level architecture work with kanban and achieved instant success in our organization. Combining the principles of the product development flow with the current large-scale agile and lean software development is a really novel concept. Well worth reading and trying out the ideas here.”
Santeri Kangas , Chief Software Architect, and Gabor Gunyho, Lean Change Agent, F-Secure Corp.

“Dean Leffingwell and his Agile Release Train (ART) concept guides us from teamlevel agile to enterprise-level agile. The ART concept is a very powerful tool in planning and managing large software programs and helps to identify and solve potential organizational roadblocks–early.”
—Markku Lukkarine , Head of Programs, Nokia Siemens Networks

22 Responses to “Agile Software Requirements”

  1. 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!

  2. Andrigo says:

    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

    • Dean Leffingwell says:

      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.

  3. Kelly Russell says:

    Hi Dean,
    When are you anticipating that your new book will be published?

    Thank you!

    • Dean Leffingwell says:

      Kelly,
      Probably midsummer to early fall. Let me know if there are pieces you need in advance.
      Dean

  4. [...] Agile Software Requirements (the book) [...]

  5. [...] Agile Software Requirements (the book) [...]

  6. [...] Agile Software Requirements (the book) [...]

  7. Jeremy McGee says:

    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?

    • Dean Leffingwell says:

      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.

  8. Jason Moccia says:

    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

    • Dean Leffingwell says:

      Sorry Jason, no real experience to draw on.

      • Jason Moccia says:

        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.

Leave a Reply