In agile/scrum user stories, how much detail is enough? [closed]

Question

Enough detail is enough is the usual response.

On the project we are currently busy with (which was incomplete and handed over to us without any brs/documentation/user stories of any sort, we get stories like:

As a Product Owner I need the developer to test the XXX workflow so that it works correctly.

and

As a Product Owner I need the developer to test the YYY workflow so that it works correctly.

No indication is given of what "correctly" means.

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.

Is this what agile is supposed to be like?

Tjon

I'm voting to close this question as off-topic because it is not about programming. – Matadi

Answer 1

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.

Brow

This answer sounds cool... problem though is that we only see the PO at standups and he is in meetings most of the time... – Tjon

This is a major impediment: if the PO is not available, you can't do Scrum, especially if people don't give you good user stories. You have a big problem here, maybe the actual PO is not the right person... Your ScrumMaster needs to solve this. – Brow

+1: Agile is about interaction between developers and PO. Not the PO telling the developers that it will eventually become clear. How will it become clear without the PO explaining? – Homecoming

This is a good answer. "Correctly" may in some cases mean just something as broad as "Page loads completely" but that doesn't mean it shouldn't be specified - just don't go into atomic details, it's important to identify only the relevant parts for each story. – Vu

When Agile is being driven from the development portion of the business, the PO role is usually weak or non-existent. I've seen development managers attempt to fill this role with varying levels of success. The key in this issue, however, isn't that the PO is failing, the ScrumMaster isn't insuring their is enough detail to make sure the story is reasonably well understood (however they get there). – Kutuzov

Its very subjective when talking about the details. A 'enough detail' sometimes appears 'insufficient' or sometimes 'nit-pick'. I feel its very tough to find a balance. Personally I don't like too much of details which are sometimes just not possible to put on a document. But these are sometimes unavoidable especially if you deal with Offshore teams. From Agile manifesto: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. I like this discussion too: artima.com/intv/fixit.html – Heartless

I like the answer, but it's still not clear enough to me. The PO provides details in conversations, but should they then be added (documented) to the original user stories? Where is the "memory" of the detailed conversations? – Raw

Answer 2

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.

Throaty

+1: If the user story is "Developer tests some component", that's really not much of a user story. That's just a "to do" list. Not a product. – Homecoming

agreed the stories are strange. that is why they have not been completed yet. If you don't tell me what it is supposed to do, you cannot expect me to tell you that it functions correctly – Tjon

Good pattern for stories is: In order to <have business value> as a <role> I want <functionality>. Business value should be valuable for role. Role should be application/business role (Customer, Regular customer, Sales manager etc) not role of development team. Functionality should be application feature what gives business value for role. "In order to have faster checkout as a regular customer I want to store my credit card information in my account" – Throaty

Answer 3

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.

Quartzite

Answer 4

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.

Akvavit

Answer 5

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.

Gati

unfortunately this is sprint 5 of 4 with a "supposed" revised tech ready date of 5 dec which has been postponed. Where one of the sprints was even extended by a week half way through. – Tjon

That is impressive, sadly that is the standard when it comes to Agile development. – Gati

Answer 6

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.

Thermonuclear

Answer 7

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

Finegrained