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.

  • 2
    Do you have specific doubts about it? Because "Uh, yeah, sure." would be a pretty lame answer.
    – nvoigt
    Apr 25, 2022 at 5:07
  • 1
    1. Please excerpt a sentence or short paragraph related to your question. Asking people to click on a link to understand your question is not considered good form on PMSE. 2. Please expand on your question a bit, as it's unclear what your actual concern or problem is. 3. Ensure your question invites canonical answers, rather than creating an open-ended discussion. 4. Welcome to PMSE!
    – Todd A. Jacobs
    Apr 25, 2022 at 14:29
  • Gherkin syntax is fine for all sorts of backlog items, and helps ensure the Definition of Done is discussed up front. Beyond that, I'm not sure what your real question or practical issue is.
    – Todd A. Jacobs
    Apr 25, 2022 at 14:31

2 Answers 2


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.