Written by South African Agile coaches Samantha Laing and Karen Greaves, “Coach’s Guide to Agile Requirements” is a book on how to teach the concepts of Agile requirements. It provides a complete plan to run a workshop where people can learn how to elicit, refine and organize requirements in an Agile way.
The training proposed by the book is based on the approach named “Training from the BACK of the room (TFTBOTR)” that split each sessions in four parts. These 4Cs are:
* C1 – Connections: To get participants to connect with each other and the trainers, and to connect participants to what they might already know about the topic
* C2 – Concepts: Some facts and theoretical concepts about the topic
* C3 – Concrete Practice: An activity or simulation to experience the topic
* C4 – Conclusion: An opportunity for participants to evaluate what they have learned about the topic
The book covers different aspects of Agile requirements: user stories, the INVEST technique, acceptance tests, splitting stories. This produces the material for a full day workshop on Agile requirements. Every aspect is discussed using the 4Cs mentioned above, explaining what to teach and how to practice the topic. An appendix provides more explanation about the proposed exercises. With the book you can also download a coach toolkit that contains the training plan, a 4Cs template, slides and other interesting material. The book is clearly structured and easy to read.
Even if this book is clearly focused on training people for Agile requirements, I think that this book is beneficial not only for Agile coaches and trainers, but for every people involved in producing Agile requirements as they will get a view on all aspects of this important activity for Agile software development.
Quotes
Have you ever looked at a requirement document that’s 50 plus pages long and wondered if there was an easier way to communicate? Or have you ever received a 1 liner story without any context and thought “huh?”. We have and in our years of work in traditional waterfall organisations and newer agile organisations the trend continues. Very seldom is the sweet spot in the middle achieved. In every single case the path to the sweet spot started with conversations.
Even if you are using a tool, what is important is that the card is just a ‘reminder of a conversation’ that needs to take place. It is useful to contrast it to a detailed requirements specification. Clearly everything you need to know cannot be contained on a single index card. People often say “If you can’t fit everything on the card, use a smaller card!”. This emphasises the point that the card is not supposed to contain all the information.
Using mindmaps can help people to brainstorm a wide number of potential acceptance tests. These can then each be discussed to determine which are actually important. However it is better to create the mind map first before filtering as some of the unimportant ideas might trigger other ideas which turn out to be critical. Mindmaps help reduce the number of unspoken assumptions that are made about what to test, because they help people have a conversation about exactly what should be tested and what is unimportant.
Many teams new to agile who struggle to finish stories in a sprint often delay the testing to the next sprint. They then reason that the development work and testing work should be separate stories. This is not a good idea as it tends to make teams believe they have progressed further than they have in reality. I.e. “it’s just the testing left so we are nearly done. In Scrum nothing is done until we know it is working, therefore nothing can be done before it is tested. Rather reduce the scope of the story using one of the other techniques listed above.
Reference: Growing Agile: A Coach’s Guide to Agile Requirements, Samantha Laing and Karen Greaves, http://leanpub.com/agilerequirements