Should user stories be delivered orally?

Question

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.

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?

Answer 1

With agile it is a good idea to think in terms of the outcomes you want first and then to think about the methods you can use to achieve those outcomes.

When following an agile approach we want to deliver great software, but also be ready to handle changes that may come along. One thing that can help with this is to not invest too much time adding detail to requirements until they are close to being worked on. We also recognise that to respond well to change we need good communication and a good shared understanding.

The idea of user stories is to help achieve these outcomes. We can create a user story with a single line of text. This makes the user story lightweight and it can be easily understood (by the Product Owner, stakeholders, etc.). However, at some point we want the development team to build the feature and they will need more information.

This is where the just-in-time agile approach comes in: We add detail to the story just before we start to build the feature. The timing is something the team experiments with until they feel they have a comfortable balance between being able to accomodate change and ensuring that feature development works smoothly.

A typical way to add detail to a story is to have one or more conversations between the Product Owner and the development team. This process may well include adding written details (e.g. acceptance criteria, UX designs, etc.).

Yet, management thinks we're a shining example of agile practice.

Your management team believes that by adopting agile methods they become agile. They have read that a user story is just one line of text and that conversations are more important than detailed documentation. However, they haven't thought about why these things are important or they wouldn't be using their current approach.

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

There are high profile agile companies (such as Spotify and Salesforce) and numerous less well known companies that follow a genuine agile approach.

You have a choice to either seek out these companies or to try and encourage a more agile approach in your current company. If you choose to stay, I would focus on getting them to think about (and measure) outcomes, rather than blindly following agile methods.

Answer 2

A User Story is a promise of a Conversation.

This famous phrase 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 ShuHaRi 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 tweet from him talking about it but the link is broken.

Answer 3

Quick Summary

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.

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)?

To answer the core of your question, user stories (if used) should not consist solely of single-line titles unless they're self-explanatory and the additional detail is unnecessary for effective communication about the work item. A lot of the rest of your question smells like a framework implementation anti-pattern since it implies a lack of full-team collaboration and whole-team communication, but I focus the bulk of my answer on your questions about how to format, refine, talk about, and (most importantly) use backlog items.

Methodology for This Answer

Since your question was specifically tagged scrum, I provide a canonical Scrum answer along with some effective practices based on my own professional experience. I also address the use of Product and Sprint Backlog items, user stories as a way to represent backlog items, and the intent behind the use of user stories (as opposed to specifications or other formats) to create conversation placeholders that increase the effectiveness of the framework's empirical control underpinnings such as emergent design, just-in-time planning, and inspect-and-adapt feedback loops.

"Agile" frameworks of other stripes often leverage Scrum or Scrum-like practices, so this should be applicable to those frameworks, too. However, frameworks other than Scrum may use a different definition of user stories, or handle backlogs and refinement differently. In such cases, your mileage may vary.

User Stories

Scrum doesn't require "user stories" at all. It requires Product Backlog items (PBIs), although in practice most Scrum teams do use user stories as defined by Mike Cohn in his book User Stories Defined or in the commonly-used Connextra format. However, the Scrum Team (and more specifically the Product Owner) can use any format desired and useful for the Product Backlog.

According to the 2020 Scrum Guide:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

As far as the Scrum framework is concerned, that's about all there is to say on the subject. Of course, years of implementation have lead to some additional considerations.

PBIs Should Get Decomposed Ahead of Sprint Planning

A PBI simply needs to be an item stored on the Product Backlog. The Product Owner manages the Product Backlog, although they may take input from stakeholders or other Scrum Team members.

Pragmatically, stories near the top of an ordered Product Backlog should meet some "Definition of Ready" before Sprint Planning. This is the primary agenda item for Backlog Refinement, which is is not a formal event in the 2020 Scrum Guide, but is nevertheless an extremely common practice. During Backlog Refinement, the whole Scrum Team works together to help break down epics and themes for near-term Product Backlog items into items more suitable for Sprint Planning. That generally includes decomposing them into smaller, more testable, and more well-defined items in accordance with the principles of the INVEST mnemonic.

User Stories are Conversation Placeholders

Regardless of the format, PBIs, Sprint Backlog items, and user stories are meant to be informative, but they are really still just conversation placeholders.

For example, I typically tell teams that a good user story should identify:

1. What should be done (at a goal-oriented level) to contribute to a cohesive Increment as defined by the current Sprint Goal. Per the 2020 Scrum Guide:

   The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

2. The Developers build a Sprint Backlog from the PBIs and determine how they will meet the Sprint Goal.

   • The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
   • The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
   • Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

Placeholders Support Emergent Design and Just-in-Time (JIT) Workflows

Note that even though the Sprint Backlog contains a plan for how the Developers plan to deliver the Sprint Goal, Scrum is an empirical framework that relies heavily on emergent design and JIT planning. As a result, the plan doesn't have to contain detailed specifications or exhaustive detail. Instead, good user stories usually contain:

1. A clear Definition of Done for the work item that covers anything not already part of the broader Definition of Done that applies to everything the Scrum Team delivers.
2. A well-defined set of value consumers and collaborators, when possible. Common stand-ins like roles, personas, or other such identifiers help the Developers plan and coordinate the work, and allow them to reach out about work-in-progress to ensure what's being built during the iteration has the right inputs, external resources, and is ultimately fit for use. In addition to ongoing collaboration within the Scrum Team, these are the conversations that the backlog items should clearly identify as placeholders for additional, just-in-time conversations throughout the Sprint.
3. A clear value statement to provide guidelines, scope, and intent to the Developers as they plan the work. Without the why part of it, there are often dozens of ways to implement a given feature. The value statement (in Connextra format, this is the "so that..." statement) helps the team choose among multiple implementation paths to most effectively and efficiently meet the defined objective.

Since these types of backlog items are really placeholders, the level of detail can vary. If everyone on the team already knows what "embiggen the widget" involves, there's not a lot of value in writing a long user story to document the specifics. On the other hand, "make the frobnicator more user friendly" doesn't really say enough about what that means, who's impacted (user friendly to whom, exactly?), or what the problem is with the current frobnicator or how the Developers will know they've met the objective for the current iteration.

Conversation Placeholders Create Buy-In and Collaboration

Because Scrum is iterative and incremental, building what was asked for but not what's needed is less common than frameworks that rely on big, upfront design with detailed specifications. Still, without ongoing collaboration within the team and with stakeholders or end users, the goal should be to leverage conversation placeholders so that it happens less often, and helps to ensure everyone knows that they participated in what was delivered this iteration. If it turns out that it isn't fit for purpose, or otherwise needs rework or refinement, then that comes out in Sprint Reviews and other non-framework conversations, and gets cycled back into the Product Backlog process.

That's what the framework's feedback loops are for. Conversation placeholders just help to reduce the blast radius of mistakes made from treating "user stories" as specifications etched in stone.

Answer 4

With various degrees, all companies are dysfunctional in one way or another (and some more than other), but everyone thinks they are doing fine and dandy. Of course they're not.

The same applies for Agile. Everyone now is "doing" Agile (mostly the Scrum variant, or SAFe if you are "doing" Agile at scale) and everyone thinks they are doing fine and dandy. Of course they're not.

Agile is not something you do, it's a mindset, it's something you are. It's not an ISO standard that lays down a formula for you to apply, or a process with well defined steps that you need to follow... and presto, result guaranteed.

To be Agile, you have to think. And many don't want to think.

To be Agile, you have to change. And many don't want to change.

They reach out for some canned solution (e.g. Scrum, SAFe) and follow that like zombies crawling after the smell of blood. They don't think about what they are doing, and they don't look at themselves doing it.

Agile is about "inspect and adapt", but I rarely see people inspecting or adapting.

For Agile to be successful, upper management needs to support the adoption and create an environment that is conducive to Agile. But they don't. Because they don't want to change (they still plan yearly, or want a six months detailed roadmap in the form of a Gantt chart, or requirements documents of 100 page each signed by three different managers for approval, and deadlines set to a specific date in the future by someone who's not even involved in the development of the product, etc.) and they don't want to think (Is what we are doing working? Yes? No? What are we doing well? What are we doing not so well? How do we know how to distinguish between the two, etc).

Agile has unfortunately become a buzzword and everyone is now using this word (together with many other changes in vocabulary with new words like Scrum Master, Product Owner, Squad, Chapter, Epic, User Story, Story points, etc). But that means squat if you are stuck in a rigid mindset and you don't really want to change.

So what you are describing looks dysfunctional to me. And no matter what words the company wants to use to describe what they are doing, that doesn't make it less dysfunctional.

You are not describing Scrum, or Agile for that matter. And no, user stories should not be delivered orally.

You can start a conversation orally, but then you need to capture more details in one form or another to share with others (you gave some examples) simply because people forget, or they understand things differently. And if everything happens by word of mouth, even if by some miracle you build what's needed, the code will be the only source of written information and not many can read code (especially since you mention 50% managers within the team, which is another weird setup for something deemed Agile).

Like I said, to some degree or another, all companies are dysfunctional in their Agile implementation. You just have to work for those that are less so than others. Sometimes you can find out how dysfunctional they are from the interview, by asking the right questions. But sadly, many times you only discover how dysfunctional they are after you've worked there for a while.

EDIT: after the question was updated.

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

It depends on the story. Something like "As a user I want to login into the application..." will probably sit as a one liner, where the details can just be something like "use industry best standards". On the other hand, a feature that requires to calculate insurance premiums with discounts and loyalty bonuses will probably need very detailed specifications, where you spend some upfront time to clarify things, write them down, and make sure they are properly understood before you even write a line of code.

Agile says, "Working software over comprehensive documentation", so documentation in Agile is build as needed (or just in time), and with just enough details to support shared understanding of what needs to be built. Some features need less details before building them, some will need more. There isn't a rule where to draw the line. But keep in mind that producing more than needed can cause waste, since you either abandon the documentation once it has served its purpose, so you want to invest less in this type of activity if you trash it; or you have to keep it up to date while building the product, and if there is a lot of it, it will take a lot of effort to keep it updated). So a lot of common sense needs to be involved here; you need to think, experiment with things, inspect, and adapt.

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?

Those are "placeholders" to track and manage the activities in the current Sprint. The sticky notes are thrown out at the end of the Sprint, but they don't retain all the conversation that took place, or all the details and material gathered or built to support that conversation and shared understanding. So yes, the documentation is stored separately. Many teams use tools like Jira or Confluence which retain the details and keep track of them. Even if you have a physical board, the sticky notes usually contain just a short title and an ID to the Jira issue that you can use to find out all the other details.

Answer 5

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

First, you are right. What you describe is not Scrum. Not even by the few rules Scrum has. Like playing soccer with twelve people and a chainsaw per team, it's close, but also horribly wrong. It's not you, it's them.

There are enough companies doing Scrum properly. Or not doing Scrum at all and finding their own way to do it. Which is fine, too. Scrum is not a silver bullet. Scrum doesn't claim to be. The only thing Scrum asks is to not call it Scrum if you don't follow the rules. And even that simple rule seems to not have been followed in your company.

In your next job interview, ask questions. Let them describe their "Scrum" to you. You won't take the Democratic People's Republic of Korea as either democratic or a republic or for their people, so don't just blindly believe what a company tells you about "Scrum". Let them describe it. Ask questions. An interview is a two way street. They decide if they want to hire you, you decide whether they are worth working for. Use that power. Don't work for a company that you don't want to work for.

Those companies exist. You need to find them.