Which Gherkin Scenarios go in which Feature File

I believe that you should break the link between Gherkin files and the Epics / User Stories that triggered the Gherkin Scenarios. The Gherkin files should be organised in a way that usefully describes the evolving product. You need to accept that a User Story can affect Scenarios in multiple Gherkin files. Once the User Story is done you can and should forget about it. But the Gherkin Scenarios have a life long after the User Story is gone.

Continue reading

User Story Dependencies are more Apparent than Real

What do I do when a User Story is dependent on another? Well, the most important thing is, to quote the Hitch Hiker’s guide to the Galaxy, “Don’t Panic!”.

I believe dependencies between User Stories are often over played. Sure there are dependencies but often these don’t require any particular management. But even more common are invented dependencies, i.e. dependencies that are more apparent than real. This means dependencies for me are a bit a of requirements smell, i.e. something to be worried about.
Continue reading

Three Ways to Control Scope in an Agile Programme

I both embrace change and also fight like crazy to reduce scope creep. On my current programme I use three main techniques to control scope: Programme Vision, Release Goal, and Requirements Trade-off. In different ways all of these put the business in control of what is in/out of scope. But they all help me stay within budget and time constraints.
Continue reading

Specification by Example versus Behaviour Driven Development

Personally I favour the phrase “Specification by Example” over the more commonly used term “Behaviour Driven Development” (BDD). That is because I demand the specifications are by example but only encourage my developers to do outside-in test first development (from BDD).
Continue reading

User Story Format Should Not Be a Straight Jacket

I use the formal “As <user role> I want to <action> so that <goal>” format when it helps. The main value of the format is it puts the focus on the users rather than on technology components. So if the user story is about user facing functionality then I will usually use the formal format as a back up to the shorter name of the user story.
Continue reading

Agile Requirements Snail: Feature to User Story to Scenario

The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.

I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.

The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:

Agile Requirements Snail

Agile Requirements Snail

Continue reading