Level of detail of a refined user story in SCRUM

Question

The main subject of my question are the user stories, after they have been put in the backlog, discussed, refined and ready to be put into the upcoming Sprint. Do they have to list all the possible detail and all the possible scenario?

Our team of 10 people spent almost 3 hours of the Refinement meeting discussing every possible detail of a simple App page that asks for an OTP, and after Confirm is pressed, either goes to the next page if the OTP is good, or display an error if not:

We wrote in detail (Using JIRA), inside the description of the User Story every possible scenario like what if the user deletes a single digit with the keyboard, what if he taps on the last input cell before writing the ones before, what happens if the user goes back and then goes to this page again, what happens if he writes just one digit then taps on confirm so the error label shows and then delete the digit again, what happens if there is no connection, if the user puts app on background and resumes it and the list goes on... The "refined" Story inside the sprint was more than 50 lines of text. Split in more than one story is not considerable as it constitutes an "atomic" functionality.

Is this normal? Everybody on the team say you have to put every possible detail or your User Story cannot be considered "ready" to be worked inside the Sprint.

And, after a story has been developed, we often have this absurd blame-game between Testers, Devs and even PO that makes everybody want to list every possible detail/scenario/use case:

Test Manager or PO: "I'm sorry, I cant consider this developed story you worked on 'Done' because if you insert this special character validation fails" -> Dev who worked on the story: "Where it is written? There is no such use case inside the Story so the Story should be accepted"

It looks like Waterfall divided in Sprints to me. Shouldn't agile be more flexible and iterative? I really believe that details emerge while you work on a functionality, it's not possible to know every detail before "testing" it.

Answer 1

In short

No, a user-story is not a detailed specification of what is to be done or what is to be tested !

Some more arguments

Purpose of the story

With a view to the agile manifesto, we prefer individuals and interactions over processes and tools. With this in mind, we shall keep in mind the 3C of stories, and in particular:

A user-story is a placeholder for a conversation

So the user-story is only a tool to facilitate the interactions and to materialise the user need in the backlog. It should focus on the user’s needs and intents: “As a user I want .... in order to ....”.

Level of detail

We also prefer working software over comprehensive documentation. We do not want a complete specification before starting to implementation.

This does not prevent that we write down some notes in order not to to forget our conversation or the quality criteria:

• But does the user care about these details ? If you ask the user and he/she confirms huge interest in the way the last caret is handled, why not.

• And what-if you would provide a different behavior, provided that the user’s needs are satisfied, would it really matter ?

Your full story including the success criteria, shall be of interest from the user point of view.

I have the impression that what you describe to us here is far too detailed. The goal of the user story is not to collect detailed test scenarios: it’s not called tester-story. And if the developer can develop based on the story, the tester can certainly prepare more detailed test-cases if needed.

Alternative

Instead of putting the test-scenario up front in the user-story, the test cases could be developed JOINTLY with the development of the feature. No waterfall anymore, but parallel, integrated teamwork.

Answer 2

I think it is worthwhile to quote the second half of the Agile Manifesto here:

Customer collaboration over contract negotiation

Responding to change over following a plan

So, rather than focusing on specifying every little detail in your story ("contract negotiation"), collaborate with the customer to clarify the requirements as you work on the story. Quite often, you won't know what details are important until you start implementing the feature.

If you can demonstrate that you have reasonably implemented the requirements of a story, you should accept it and move on. If you later identify a requirement that was missing in the original story, create a new story for it ("responding to change").

Answer 3

In your example, you want to specify everything precisely before anyone actually has tried it out. That's not possible. You can't design things at a table, implement the design, and then just hope that it works out. You have to create things, and then see if they work, and if they don't work, redesign.

So you should keep things less fixed in your user story. Your screen looks quite reasonable there, plus obviously what should happen: If the user enters six digits then they can press "Confirm" and the code is either accepted or not, if they don't enter six digits they can't press "Confirm". That's it.

Now if QA finds that entering an emoji instead of a digit crashes the app, that's another story. If you find that the user can't cancel the operation, that's another story. If you find that the user can't request to resend the OTC that's another story. If you find the user can't fix typos that's another story (although I would say I would have expected the first and last of these four points to be handled as part of the original story, and saying "nobody told me the app mustn't crash when you enter an emoji" is really a lame excuse.