1

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:

Text

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.

Improve this question
2
  • As it stands, this question is very unclear and the answers are highly subjective. Also, i think you are asking the wrong question. Your real problem are developers refusing to address bugs without a special bug ticket or requirements in the story. I suggest that you ask instead how this problem can be solved.
    – marstato
    Nov 13, 2019 at 12:38
  • 1
    @marstato that is just a side effect and an argument I always get in defense of writing all the possible details in the user story. The question is just about where and if the most specific and little details should or shouldn't be written, and I've got satisfying answers :)
    – Stack Diego
    Nov 13, 2019 at 13:09

3 Answers 3

Reset to default
3

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.

Improve this answer
2
  • So is there a place in Scrum for such details? Or are them discussed and figured out while working on the story?
    – Stack Diego
    Nov 13, 2019 at 9:10
  • 1
    @StackDiego I edited. No, there’s nothing foreseen. The way you handle test cases shall be defined in the team’s definition of done (dod). In fact user story is a requirement, the developed feature is a solution, and the detailed test-scenarios depend not only on he requirements (that part is the success criteria) but also on the solution (this part can’t be an input). But the solution needs to be tested to be accepted (so test scenario are not a final output either). Conclusion: detailed test-scenario are a coproduct of the development activity. It’s produced in the same time than the feature
    – Christophe
    Nov 13, 2019 at 9:58
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").

Improve this answer
2

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.

Improve this answer
1
  • I would even differentiate between "entering an emoji crashes the app" which could block acceptance of the story and "I am able to enter an emoji in a field that is supposed to be numeric only", which can be classified much less severe (and as a new story) depending on how easy it is to enter that emoji.
    – Bart van Ingen Schenau
    Nov 18, 2019 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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