Should user stories be delivered orally?



  • I have studied software engineering and learned a decent amount about requirements engineering. I also took a course in Scrum.

    I've now worked at several different companies, and so far, I haven't seen anyone following the principles and practices that I've studied. I read somewhere that 95% of companies use a "hybrid" DIY agile approach, which seems like an excellent way of saying that "we make up the rules as we go."

    Our current practices aren't working for me, and I wonder if the problem is with me or if the practices aren't following recommendations.

    My current company has all user stories and tasks written as a single line of text. All details are delivered orally by the Scrum Master / Team Lead, who has separate discussions with the Product Owner without the developers.

    Aren't stories supposed to be specific and scoped, refined together with the developers (ready to work, to address ambiguity), and have clearly defined acceptance criteria (definition of done)? And perhaps a UX specification/screenshots/sketch drawings?

    Maybe a one-liner would work fine if the team was small, co-located, closely collaborating on the same tasks, and had a high degree of freedom of interpretation. But we're a larger team (~30 people, 50% managers), with a long one-way decision chain (Product Manager -> Digital agency -> Product Owner -> Delivery Lead -> Team Lead/Scrum Master -> Developer).

    Yet, management thinks we're a shining example of agile practice. The project cost, so far, is probably around $2 million, we're a year in, the website still hasn't been used by any end-user, basic functionalities that are obviously necessary are missing, but everyone is happy and celebrating with champagne.

    And it feels like most other companies have the same practices.

    So what can I reasonably ask for in the real world of companies that follow agile best practices?

    Edit/Addendum, to focus my question and not sound like a rant:

    This diagram suggests that stories can be large (epics), which can be broken down into smaller, more workable stories, but also that more detail is added.

    enter image description here

    How much detail should be written and explicit? Or is it entirely reasonable that all details remain implicit, stored in the team's collective memory?

    Scrum boards are often depicted as having only sticky notes. And presumably, those sticky notes are trashed when the sprint is done. So do such teams maintain documentation separately or have none at all?

    enter image description here



  • A User Story is a promise of a Conversation.

    This https://en.wikipedia.org/wiki/User_story was said by one of Agile Manifesto authors, Alistair Cockburn*. So yes, a User Story can be a one liner.

    But aren't stories supposed to be specific and scoped, refined together with the developers (ready to work, to address ambiguity), and have clearly defined acceptance criteria (definition of done)? And perhaps a UX specification/screenshots/sketch drawings?

    These are not mutually exclusive arguments. The key is when in time each happens. The Product Manager may write a one liner - as a promise of a conversation, have this conversation with the team and then, together, to expand this one liner into a list of agreed acceptance criteria.

    Agile frameworks, in general, are non-prescriptive on purpose. It allows every team to explore the best way to implement it. It's sad that most places try to mimic what other places do, forgetting each company, each context, each person is unique.

    I read somewhere that 95% of companies use a "hybrid" DIY agile approach, which seems like a nice way of saying that "we make up the rules as we go". Our current practices aren't working for me, and I'm wondering if the problem is with me, or that the practices aren't following recommendations.

    This is true and happens more than it should. It's important to know, however, that this happens as people may move into customise the framework without entirely understand why the framework suggests some practices. Understanding https://martinfowler.com/bliki/ShuHaRi.html may help understand the problem several teams face: they move into Ha, before getting the Shu.

    Expanding on top of the known frameworks is suggested by practitioners and authors. You'll no longer be doing Scrum, of course. But you can still be agile in your own way.


    *There's also a https://twitter.com/totheralistair/status/897894659544031232 talking about it but the link is broken.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2