Although many might tend to limit the concept of agile requirements to “user stories”, this book by Dean Leffingwell reminds us that there could be more than just a post-it on an information radiator when we talk about Agile requirements. The title of one of the initial chapters is “The Big Picture of Agile Requirements” and this book provides it, together with the small details that can help you write better user stories.
Dean Leffingwell describes the general context of managing requirements in organizations based on a three levels view: portfolio, program and team. The concept of requirements is different at each of these levels: from the investment themes and epics of the enterprise strategy to the user stories implemented by teams during Scrum sprints. An interesting concept developed in the book is the Agile Release Train (ART) that aggregates user stories in features set. The goal is to adjust the Scrum team’s capacity to produce software with the ability of customers to absorb it.
The book is very well written, achieving a balance between a structured approach and easiness to read. It contains many case studies, templates and sample agenda that help relate the ideas expressed with the daily activities of Agile software development. Three appendixes at the end propose interviews and document templates, along with a release-planning checklist. This book provides a detailed and extensive study of the Agile gathering and management of requirements in enterprises and I will recommend it to everybody involved in some software requirement activity, from the business analyst to the project manager or software developer.
Reference: Agile Software Requirements, Dean Leffingwell, Addison-Wesley, 489 pages, IBSN 978-0-321-63584-6
“One of the first questions that arises at this level seems like a basic one: how to organize the agile teams in order to optimize value delivery of requirements. […] At scale however, like most other agile, the problem is different, and the challenge is to understand who works on what and where. Do we organize around features, components, product lines, services, or what? Although there is no easy answer to this question, the question must be explored because so many agile practices – how many backlogs there are and who manages them, how the vision and features are communicated to groups of teams, and how the teams coordinate their activities to produce larger solution – must be reflected in that decision.”
“A typical challenge facing teams is learning how to write small, incremental user stories that can effectively deliver value. Traditional approaches have taught us to create functional breakdown structures based on technical components. This technical layering approach to building software delays the value delivery until all the layers are brought together after multiple iterations.”