I'm talking about using Cucumber's Gherkin style syntax such as GIVEN ... WHEN ... THEN. I read a post and really liked the idea. However, the author doesn't expand on how he uses the "Living story" for technical details of implementation.
Given that Gherkin style acceptance criteria are pretty descriptive, I feel like it might work decently. I'm still learning agile so I'm not sure if this would be bad practice.
I'm not a fan of the idea of "living stories". Although living stories and building and maintaining more detailed acceptance criteria may work for the author of that post, I've found that it doesn't scale well for other situations. The author is coming it at from the perspective of an agency building some software for a singular client and then likely handing it over or transitioning to a different maintenance team. Maybe it works fine there, but coming from a background in product development where you will be building a system for dozens or even hundreds or more of potential customers and maybe even more classes of end users and maintaining that product for many years to come. I tend to view stories as point-in-time deltas between the current system and the desired system.
Strict criteria for the content and structure of a user story also bothers me. Whether it's the user story format (which came from a company called Connextra - it wasn't a part of the original idea behind stories and story cards from the C3 project that launched Extreme Programming) or a format like given-when-then for acceptance criteria, the emphasis is shifted away from understanding the problem to representing the problem. Although understanding these formats could be useful, ensuring that the stakeholders and the team have a shared understanding of the problem and the team can build something appropriate is far more important than sticking to a single format. There may be work that isn't well-represented by one format over another, so forcing unnecessary standards onto the team doesn't help the team be effective.
All of that said, if the team sees value in using the given-when-then format then that is not only easily translatable into something that stakeholders can read and discuss, but it can also be translated into test frameworks like Cucumber so the way the test is written is also understandable by the stakeholders. This is a key aspect of Behavior-Driven Development, which can also pair nicely with Test-Driven Development and/or Acceptance Test-Driven Development, or other test-first strategies.
My recommendation would be to focus on the tests, which become the executable specification for the system. Using test frameworks that let you write system-level tests in a way that can be easily exported and read by stakeholders is extremely valuable. Since the tests should be maintained with the system in order to keep being useful, they should always be correct - even more so than the story cards on a board or in a tool like Jira.
You can approach something like this -
User story: As a ABC App Product Team Member, I want to do X, So that App/User can do Y.
Acceptance Criteria: Given certain framework/solution is ready-to-use, When ABC App calls an API, Then ABC App should receive the following response code: And ABC App should do the following next: 1. 2. 3.
Additional Acceptance Criteria: Dev Notes: XYZ QA Notes: PQR
