When dealing with requirements information in agile development, there are many work practices that propose instruction and advice. But sometimes it can be difficult to keep up with the many options: Which of these practices are particularly important? How do they relate to each other? This article offers you orientation and guidance in the wide and growing field of agile requirements practices. It shows which practices are essential, which can be useful additions, and when you should focus on what. The figure presents a map of agile requirements practices. All listed practices can be useful to agile requirements. Those highlighted in light blue font color are particularly important. And those in the Core Practices area represent the backbone and starting point of requirements activities in agile development. Let’s walk through it one step at a time … 
Start with User Stories, Backlog and Little More
The contents of the Core Practices area drive agile development with regard to requirements. They are essential building blocks of Scrum, the most widespread agile development approach. Product backlog and sprint backlog are used to define the work to be done. From a requirements perspective, user stories and epics are the most relevant kinds of backlog items. Sprint goals define the requirements context of a development iteration, and the Definition of Done can be used to establish quality requirements. When you search for advice on these practices, take a first stop at the Scrum Guide and explore topics further using the Agile Alliance’s glossary of agile terms. Later you may deepen your understanding with Dean Leffingwell’s seminal book on agile software requirements. Specifically for user stories, your information sources of choice can be Mike Cohn’s blog articles and his book. You might wonder why the map does only list but not highlight the product owner role? The answer is simple: I assume that you are already familiar with this role. Quite likely you even are a product owner. The highlighted practices all are artefacts that can help product owners doing their job well. Adopting such artefacts or work products (as opposed to new job roles or procedures) usually is the most direct and easiest way to establish new practices. Artefacts that are not highlighted are less central to agile requirements management. And generally, for the reason above, roles-related practices like feature teams and the three amigos are not highlighted. Neither are procedures like sprint review and product backlog refinement. Of course, they can be very important at times. Let’s continue our journey to improved agile requirements practices …
Templates and Checklists Help with User Stories and Backlog
Once you have user stories and backlog in place, you might want to use them more effectively and improve their quality. You receive help from the various templates- and checklists-related practices in the Supporting Practices section. Most important is to establish a suitable user story template. The role – feature – reason template will likely be the central part of it. Definition of Ready is an instrument to set focus on quality of user story and backlog. The best one-stop information sources on these practices are, again, the Agile Alliance’s glossary and Mike Cohn’s blog articles and his book.
Product Definition and Planning Provide Direction and Context
Development needs direction and context. Product vision, product definition, and road map provide this. They need business model and value proposition as their foundations. Release plan brings the road map into action. Together, these practices provide business context and important planning guides for the requirements-related work. These practices have originated from the field of software product management. And there is a rich body of knowledge available there, which lately has also taken up many inspirations and contributions from the agile movement. Becoming familiar with the software product management perspective can be very valuable for agile product owners. The primary recommended information source on software product management is the website of the ISPMA, the International Software Product Management Association. Their free resources on the software product management framework and the various syllabi of their education scheme give both a good overview and a solid foundation. For agile concepts on software product management, the Scaled Agile Framework® (SAFe®) website and books provide the most systematic and richest information at date.
Basic Requirements Practices Give Momentum and Mastery
Agile requirements work starts from its specific angle with user stories and backlogs. But it can soon arrive at areas where traditional requirements management offers effective solutions. Examples are: How to deal with quality requirements (aka non-functional requirements)? Or how to capture system scope and context? A good entry point into the field of requirements engineering and management is the International Requirements Engineering Board (IREB). Their website offers many free resources and links to further information.
Explore and Deepen over Time
Entries from the Additional Practices and Scaling Practices areas of the above map offer additional concepts that can enrich and improve agile requirements. The Scaling Practices are important, because Scrum only addresses the situation of project-oriented development by one single team. In larger or more complex settings, and especially in continuous product development, you need supplementary approaches and practices. In addition, there are several agile practices that are not specific to requirements but that interrelate with it and affect it. For instance, tasks are derived from user stories and conduct their implementation. But usually they don’t provide specific additions to a requirement. Many other disciplines from the area of software engineering provide concepts and practices that can be valuable to agile requirements. Particularly noteworthy are architecture and design as well as testing. Also user experience design (UX design) offers very interesting and useful approaches. For scaling agile requirements, useful approaches are LeSS (Large-Scale Scrum) and once again SAFe®. An overview of agile practices in general provides the Agile Alliance. Also Wikipedia can be a good source. For general software engineering methods it is most useful to scan the web and (online) bookstores by browsing and web search.
Information Resources
The following list summarizes the links to further information. It also contains brief additional comments and recommendations. Scrum Guide: The scrum guide explains most core agile requirements practices and other agile practices. Mike Cohn’s blog articles at Mountain Goat Software: Very concise and helpful information on user stories and epics. Mike Cohn’s book “User Stories Applied” (2004): Very instructive. However, note that the role – feature – reason template wasn’t broadly known at the time and is not addressed in the book. Dean Leffingwell’s book “Agile Software Requirements” (2011): A very systematic and comprehensive treatment of the topic. This work has resulted in the SAFe® framework (see below), for which many resources are available. However, I like this book because of its coherent description and the many practical tips and examples. Agile Alliance Glossary: Comprehensive collection of relevant agile terms and crisp explanatory articles. Provides a good initial understanding of important agile concepts. SAFe® website (Scaled Agile Framework®): Very rich source of information. The homepage shows overview diagrams of SAFe®. Each item in these diagrams has a link to a detailed webpage that describes it. LeSS website (Large-Scale Scrum): A marked lean and light-weight approach for scaling Scrum, with many smart and useful agile requirements practices. Most practices can be adopted independent of the others, which facilitates experimentation and stepwise evolution of work practices. ISPMA website (International Software Product Management Association): ISPMA introduces itself as “an open non-profit association of experts, companies, and research institutes with the goal to foster software product management excellence across industries”. Provides a comprehensive, systematic, and experience-based body of knowledge with many free information resources. IREB website (International Requirements Engineering Board): A non-profit organization that fosters qualification and experience exchange on requirements engineering. A good starting point for further exploration on software and system requirements. Most of the accumulated body of knowledge can be accessed free of charge. Wikipedia: Last but not least, many agile methods and associated requirements practices are described well in Wikipedia articles. Another good starting point for quick overviews and links to further information.