Login
You're viewing the social.telemetrydeck.com public feed.
  • Jesse T. AlfordanEXPer@mastodon.social
    Sep 1, 2026, 9:13 PM

    I like to try and take part of the middle part of the Connexta format and use it as the story title.

    So from the above example the title of the story would become `set a display name`. In the style of sentence fragments used for other purposes, I don't capitalize it or end with a period.

    This is the point at which I often regard the story as ready to discuss. You can get a lot more design and specification into a story, and each team has to set their own thresholds for things.

    💬 1🔄 1⭐ 0

Replies

  • Jesse T. AlfordanEXPer@mastodon.social
    Sep 1, 2026, 9:16 PM

    People often add two things that can be really useful in a lot of contexts: explicit Acceptance Criteria and some kind of wireframe or mockup.

    In other cases, the intent is clear enough, even without this stuff, for everyone to figure out what they need to figure out from the story: what should I do, am I done doing it, was this done right, etc.

    Decide if it's enough by talking about it with the people who will need to figure out the answers to those questions while they're using the story.

    💬 1🔄 1⭐ 0
  • Jesse T. AlfordanEXPer@mastodon.social
    Sep 1, 2026, 9:18 PM

    Visual resources can be attached or linked to, as can useful notes like established schemas or standards that might apply.

    If they need contextualizing notes, you can add those.

    People use something called Gherkin to add explicit acceptance criteria. It's a formalized "given x when y then z" template, and it has the same kinds of strengths and limitations as the connextra format.

    You can do cool tooling things with it, but you can also "just" use it to structure your communication.

    💬 1🔄 1⭐ 1
  • Jesse T. AlfordanEXPer@mastodon.social
    Sep 1, 2026, 9:21 PM

    Honestly, writing out all the acceptance criteria is usually overproduction! You will calibrate what is enough in context with people over time.

    Later, developers will probably write a bunch more test cases anyway. If they come up with some to talk about while you're planning, that's all good!

    One of the main things I'd like for you to take from this is that while it is useful to have all these thoughts,

    in a lot of cases,

    when you write one story, you're done very quickly.

    💬 1🔄 1⭐ 1
  • Jesse T. AlfordanEXPer@mastodon.social
    Sep 1, 2026, 9:23 PM

    So much implicit information is developed and checked by coming up with the answers around who, what/how, and why, that people can often do what they need to do with just that. The rest of it is tools for generating additional alignment when that turns out not to be quite enough by itself.

    The other question you'll be asking about a story is "is this more important than that?"

    It's very important that question be satisfied, so you can prioritize, and reprioritize as your understanding changes.

    💬 1🔄 1⭐ 1
  • Jesse T. AlfordanEXPer@mastodon.social
    Sep 1, 2026, 9:27 PM

    So, that's how you write one user story.

    Do just enough. Let the implicit work. Use the explicit to guide and patch it.

    I've left out the part where you somehow learn and validate all this stuff you know about the people you're trying to help.

    That's very important too, and if you find yourself struggling with any part of who what/how why or unable to come to consensus about given-when-then stuff,

    you would probably benefit from talking to and watching more users to fuel your thinking.

    fin

    💬 1🔄 1⭐ 0
  • Jesse T. AlfordanEXPer@mastodon.social
    Sep 1, 2026, 9:30 PM

    Oh one more thing actually:

    I'm going to put some kind of short, free class/session/event together about this in the next couple weeks. Please reply or DM me if you're interested.

    We'll also talk about when to split or combine stories, how to choose which stories to write, how to order them, and so on.

    💬 1🔄 1⭐ 0
  • Mark Whybirdwhybird@aus.social
    Sep 1, 2026, 10:43 PM

    @anEXPer I do a lot of back-end integration work. When shoe-horned into the format, many stories look like “as system x I want to get data D in format F so I can act on it” (often there’s a “from system S” in there too, which I fight against; that’s meta info.), or else “as system S I want to safely expose data D so clients can act on it”.

    There may be a special place in hell for those who insist on saying any system “wants” anything. I fight this shoehorning of system specs into user stories constantly. Has anyone seen a good format I can throw back at them?

    💬 0🔄 1⭐ 1
  • George Dinwiddiegdinwiddie@mastodon.social
    Sep 2, 2026, 12:22 AM

    @whybird @anEXPer
    Such needs are not well expressed as a user story, because the user is hidden behind another system. I generally drop down to the language of TDD and write tests for my adapter that translates what the other system offers to what my system wants. Or vice versa.

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0