My book, titled as above, has now been published. One of the reasons I'm writing about it here was that the dev.to community played a part in my book becoming a reality. Allow me to explain the how and why.

The problem

I've been working in software engineering for well over two decades. In the last 10 years or so, I've been working with agile processes and frameworks, such as Scrum, Scrumban and others. One of the things that always struck me with agile implementations was how lackadaisical their approach to capturing and managing requirements was. I went from a bureaucratic, documentation-laden, analysis-paralysis, waterfall cycle to a "let's write a user-story and have a chat about it", 'agile' approach. At first this seemed like a really cool, laid-back way of doing things. Over the years though, I started to realise how inefficient and ineffective this approach was.

User Stories as the foundation of a development and delivery cycle are dubious, for reasons too numerous to mention here (I describe them in the book). One of their many problems is that they don't help provide a Specification, that is a way of knowing how our software will realise the users' requirements. At best, a user story will have some acceptance criteria that the developers will use to verify their code output. However, the output is not the outcome. Just because our code produces an expected result does not mean we satisfied the user's need, nor that we helped them realise their goal. To achieve that we need to work the other way round: identify the stakeholders' goals, then the impact the stakeholders need to have on our system in pursuit of their goals and finally the system functionality which will realise that impact.

The light at the end of the tunnel (no it wasn't a train)

I found Behavior Driven Development (BDD) to be a great way to create specifications that can also be verified against the deployed software. BDD is centred around Features, so the big question became "How do I reliably create or derive valid Features based on the requirements?" This puzzled me for a long time until I came across Impact Mapping. Impact Mapping allowed me to answer the big question of What, Why, How and for Whom are we doing what we're doing (spoiler: the What part is our Features). It also provided a great way to bridge the gap between Requirements and Specifications.

After years of trial and error, I finally managed to refine a working methodology for capturing and modelling requirements, creating executable specifications for these requirements and delivering them within an agile process or method like Scrum or Kanban. So for the last couple of years I'd been thinking of putting all this knowledge down in a book but I never felt bold enough to go for it. Until last year.

The Post

In April 2019 I posted my thoughts on the user-story chaos in an article titled Enough with the User Stories already! It became my most read post here on dev.to. It generated many comments and I also received a few emails creating conversation on some of the points in the article. It triggered my decision to write what I know and practice in a book, and set it free out in the wild.

The Book

So here comes the self-advertising part :) My book contains an end-to-end methodology for building the right software. It shows techniques, methods and tips for:

• Eliciting requirements from your Stakeholders
• Modelling requirements with Impact Mapping
• Defining behaviour in Features
• Writing verification code for your Features
• Creating a feature-based product backlog
• Deliver the right software within Scrum or Kanban

Along some established techniques like BDD and Impact Mapping, I also demonstrate some home-grown ones like parsing requirements with D3 and software delivery with Feature-first development. The book won't show you how to create software correctly, but I'm confident it will help you create and deliver the correct software ;)

The book is out on Packt Pub and Amazon. Hope you find it useful and thanks to everyone who's contributed to the user-story and requirements discussion.