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.
Author Archives: Steven Thomas
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
You can go a long way with a Shonky User Interface
“Shonky” means poor or low quality where I come from. I realised it was a Kiwi phrase, or at least Antipodean, when I told my current UK based team to “give me a shonky user interface (UI)”. They looked puzzled, then laughed, then asked me what I meant, then laughed again, then adopted the phrase into the team vocabulary.
Aside from the entertaining aspect of my request, it does raise two questions:
- What is a Shonky UI?
- Why on earth would anybody ask for a Shonky UI?
The Lean-Agile Fanatics are all Wrong
When Kanban folk talk to Scrum people the conversation can often get heated with recriminations and finger pointing. Personally I’ve got a pragmatic, or eclectic, style of Lean-Agile. None of the published methods are the silver bullet. But they all have something useful to offer.
Continue reading
Cucumber is my tool of choice for Specification by Example
Cucumber is my tool of choice for Specification by Example. I like Cucumber for three reasons:
- The specifications are written in plain English
- The supporting tools are very mature
- The step definitions are clean
Reporting Percentage Complete on an Agile Project
What do you do when management asks for a percentage complete on an Agile project? The flippant answer is “tell them the percentage complete”. Agilists reject percentage complete when reporting on low level stuff. But for the project as a whole you can get quite an interesting metric, one that is based on real data, so why not calculate and share it.
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
Kanban in Video, Post and Book
I’ve been using the Kanban method for several years now and I recently introduced my latest team to its joys. I do a lot of arm waving to explain the method but I also direct them to some essential viewing/reading. So I thought I’d share my Kanban recommendations – one video, two posts and a book.
Continue reading
Research on Pair Programming by Professionals
Research on Agile technical practices are few and far between. The research that exists often uses students as the test subjects so doesn’t necessarily reflect professional practice, particularly not by senior professionals. In 2006 I got my company of the time involved in some research on pair programming. What was different about this study was that the subjects were professional developers. The results were interesting as, in general, they didn’t bear out claims that pair programming improved quality or speeded up development. But pairing does take a lot more effort. This is why I am selective about encouraging pair programming, restricting my active encouragement to discovery mode.
Continue reading
Six Reasons to Adopt Specification by Example
I love the whole concept of Specification by Example. This approach ticks several boxes for me:
- Business requirements
- Concrete requirements
- Earlier conversations
- Shared understanding
- Automated tests
- Living documentation