When asking for more detail, one is informed that you are asking for too much detail and since this is agile, the requirement will become clearer later during the sprint (2 week sprint) and you should not worry about the detail just then, but rather to just give the story a weight in "doll hairs" and stop being difficult. Be a big picture guy. Don t worry about the detail.

Not really. User stories capture the essence but this doesn t mean no details. Details are transmitted during conversation and are definitely mandatory for a good understanding of what has to be done (not even mentioning that it seems hard to estimate anything if you don t know what to do and what is expected).

Communicating details about stories is actually a part of the job of the Product Owner (PO). This should occur during the first part of the Sprint planning meeting where the PO explains each stories to the team, before the planning poker and/or at anytime if any clarification is required. In other words, feel free to ask the PO for details (and ask the PO for the acceptance criteria too). And if there is too much uncertainty, put a big estimate in front of the story and explain why you can t make a "better" estimate.

To me, your PO/customer/stakeholders don t seem to participate very actively and this is a big, very BIG impediment. Your ScrumMaster needs to take care of this, there is no magical solution.

You should ask as much details as needed to feel comfortable to estimate story.

You may add some acceptance tests criteria to back side of story card (these don t have to be detailed).

As a customer I want to pay with credit card...

Test with Visa, MasterCard

By the way your stories seems a bit strange. They should be customer/feature centric.

Scrum backlog items/User Stories do not need to be very specific to be added to the Backlog.

More details is required to make them sprintable (schedulable in a Sprint). Enough detail is needed at that time so that it can be estimated, and it should have a clearly defined completion criteria.

A User Story is a promise for a conversation with the Product Owner about the scenario it covers.

Premature details are a waste.

It looks like you re using user stories here to define the process, rather than features in the system. But I don t think there is sufficient detail here for the developer to know whether the test is passed.

Also, what you ve listed here are acceptance criteria, the user story is usually more descriptive and is underpinned by one or more acceptance criteria to define the essence of the functionality.

Questions I would immediately go back to the PO with are: What is the logic for Workflow XXX? At each step what are the options? What (if any) actions are logged? What email/notifications are sent? How? to whom?

If the Product Owner can t articulate the Product AND is telling a Scrum Master how Agile works, perhaps he needs training .

Try providing a blank screen and ask him what s missing.

Often times companies do hybrid process strategies. That being said this seems like rad(Rapid application development) + scrum. If this is only the first sprint than yes that is enough detail to get started. At this point for the first sprint I would advise the team to move forward with making sure the workflow can execute start to finish, regardless of the results it generates. This often times means doing some Pokemon exception handling (catch Exception instead of specific ones), log the error and take the information into the next sprint.

It needs to describe the simplest path from beginning to end. It doesn t need to describe all of the exceptions or variations. When you come across those exceptions and variations, you ll need to have a conversation with the customer and update the story if needed.

How much detail is "enough" depends on many things. Your environment seems to point to the need for more detail.

As a start, you may need more detail in your story definition if

• your product owner is inaccessible to answer questions in real time (your team s issue)
• your team is distributed over multiple time zones
• your team members complain about not understanding what to do when they pick up stories
• your team s understanding of the domain and/or application warrant more detail
• stories have a highly visual component (say a new UI screen) for which a picture would provide an efficient mechanism to convey the UI layout