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.
Books on Scrum and Agile Project Management
Mary and Tom Poppendieck summarize the objective of the “Lean Mindset” book in the introduction: “we present a mental model of how to design and deliver amazing products that delight customers”. Following the same idea that you should “be Agile” and not only “do Agile”, the book explains how to build the mental model to act in a lean way, discussing the creation of a favorable environment and process to deliver value to the customer.
In their book “Help Work to Flow”, Samantha Laing and Karen Greaves have explored their Agile working and coaching experience to collect 40 tips, techniques and games that should allow you to work in the state of flow, this situation where you are more productive.
It all starts with doing the right thing. Agile has not changed the old computer wisdom of “garbage in, garbage out”. This is why Allan Kelly last book is dedicated to the art of Agile product ownership. As he wrote: “If a Scrum Master performs badly, the team simply fails to perform well. If the Product Owner performs badly, the whole product is in jeopardy”.
The Kenneth Rubin’s “Essential Scrum” book starts with a foreword by Mike Cohn who writes “there must be billions of possible ways to implement Scrum. And while there is no single right way, there are better and worse ways to implement Scrum.” Mike Cohn writes also “what works in one company or project will fail in another”. The presence of Mike Cohn in this book is not a surprise as Kenneth Rubin hired him in 2000 to work on the implementation of Scrum at Genomica.
Following the famous mantra of “you can’t manage what you can’t measure”, Scrum teams have often a set of metrics to monitor their activity. Velocity, the amount of work performed by a team during a single sprint, might be one of the most famous Agile metric. Doc Norton has written an interesting book about the negative sides of velocity and what might be a good metric for an Agile team.
Gojko Adzic is known in the Agile software development world for his work on requirements presented in his book “Specification by Example – How successful teams deliver the right software”. In this small and easy to read book, he focuses on a single tool that could be very useful for Scrum teams: impact mapping.