Here is an example of s story that recently made its way into a timebox.

As an Ecommerce Executive, I want to make improvements to the Request a Callback form which will make it easier to segment the callback request by purpose.

  • Can the customer select their reason for requesting a callback?
  • Can the customer specify whether they are a new or existing customer?
  • Is the form dynamic?
  • Does it reflect the design and copy attached?
  • Has the old 'Visual Website Optimizer' code been replaced with the following 'Optimizely' code:

I believe that developers and testers have a responsibility to work out the detail of stories with whatever business representatives are available and I enjoy that part of my role. However, I am left feeling a bit like I did all the analysis.

The last point in the acceptance criteria is part of another story and was completely unrelated.

Here is what the owner of the story actually desired (actually I believe there should maybe be two stories here)

As an E-commerce Executive, I want to capture and send information to the Telephone Provider for MI purposes so that I have improved granularity in the MI reports.

  • Can the customer select if they are an existing or new customer?
  • Can the customer select the product they require a callback for?
  • Can the customer select the reason that they require a callback for?
  • Are the available reasons available dependent on the product selected and
    whether the customer is existing or new?
  • Are the selected reasons sent to the provider?

As a Sales Manager, I want to route telephone calls to a specific call handling team depending on how the customer has completed the Request a Callback form so that the customer is dealt with by a suitable call handler.

  • If the customer is calling about Product X, is the new Product X route I have created sent to the provider?
  • If the customer is an existing customer, is the new Existing Customer route I have created sent to the provider for all products excluding Product X?
  • If the customer is a new customer, is the new Existing Customer route I have created sent to the provider for all products excluding Product X?

Even with the second stories, the developer an tester will still have to talk to a business representative to flesh out the exact detail. I believe this is a good thing as it allows a certain level of negotiation in order to get the best solution.

I believe the original story is difficult if not impossible to reasonanly estimate.

I also believe that it can lead to disagreements to as when the story is 'done', leading to under/over delivering.

We have raised story quality at every retrospective for a long time, but in the view of the developers\testers the story quality hasn't improved.

With regards to my example:

Are my colleagues and I falling into the trap of wanting too much defined up front or is the first story under analysed?

What level of detail\analysis should the team expect before being asked to estimate and develop the story?

  • +1 for a good question with valuable levels of detail, but it could use some judicious editing to avoid Wall of Text Syndrome.
    – Todd A. Jacobs
    Commented Jan 26, 2015 at 18:03

6 Answers 6


Your Posted "Stories" Are Goals, Not User Stories

As an Ecommerce Executive, I want to make improvements to the Request a Callback form which will make it easier to segment the callback request by purpose.

This is not in any way a useful (or even meaningful) user story. While user stories shouldn't be detailed specifications, user stories that are nothing more than vision statements aren't estimable or actionable.

Your other stories have similar issues. They all represent goals rather than concrete features.

User Stories as Features

There are lots of considerations that go into a well-written user story. Whole books have been written on the subject. However, it's safe to say that a story should use INVEST criteria to describe a measurable deliverable and a feature's context without becoming prescriptive about the implementation details.

Well-written stories will still involve some analysis and discussion to determine the best way to implement the feature, but your current slate of stories don't seem to contain even baseline assumptions about your system architecture, user interface design, or customer workflow to use as a reference point for communicating about each story.

What Better Stories Might Look Like

You should group related stories into an over-arching theme, and then strive to decompose stories into actionable features that clearly articulate the beneficiary (a.k.a. value consumer) of each feature. Each story should also contain sufficient context to guide the implementation of the feature without being overly prescriptive. For example:

  • Theme: Improve callback request forms.
    • Story: As a customer, I would like the form to provide a drop-down list of callback reasons so I don't have to enter common reasons manually.
    • Story: As a customer, I would like a place to fill in a callback reason that isn't covered by the drop-down list.
    • Story: As a call center employee, I expect a callback request to identify new and existing customers separately so that the calls can be routed to the right person on my team.
    • Story: As a customer, I expect the system to determine whether I am a new or existing customer (perhaps based on whether I have an existing login) so that I don't have to check a box for something that the company should already know about me.

Each story still invites conversations about user interface design, the trade-offs involved in implementation choices, and other considerations that affect the product and the product-development process. However, you'll know you have the right level of granularity if you don't have to read or write an entire set of Cliff's Notes just to communicate about the story.

  • Thank you. That is a lot to think about. I have always thought that the story should be thought of like a card with the format: as a type of user, I want something, so that business benefit on the front of the card and the acceptance criteria in the form of questions on the back. My bullet points would be the back of the card. I also thought that specifying that something should be a drop down was considered implementation detail and should be avoided. Your method is quite different and reminds of use cases. I will read further on this. Thanks again.
    – davy
    Commented Jan 26, 2015 at 18:12
  • @davy: I agree with you that specifying "a drop-down list of reasons" in the story is too much implementation detail, but specifying "a list of reasons" isn't as it doesn't prescribe how the list gets presented. Commented Jan 27, 2015 at 11:56


How much analysis is needed: enough analysis to enable the team to implement the user story. In most of the cases this means all information is available and there are no open questions. This should be done iteratively: the closer the implementation-sprint the more details are added.

I personally think it is a good thing that you have the intendend goals and impacts as it leaves room for conversations and discovering the problem space. At some point however you should move forward and define features / solutions. But nobody says that you cannot do that as a team.

In in an ideal world this works the following way:

  1. Present the Vision and the Impact you want to make
  2. Explore the Solution Space (map Features)
  3. Devide those Features in smaller parts if necessary (one part should be doable in one iteration)
  4. Write as little requirement documentation as necessary for those parts

The closer the feature/requirement/user story gets to the iteration it will be implemented in, the more details are added (as much as necessary to implement it). These steps are done iteratively. In Scrum e.g. you use Backlog Groomings as mentioned by Ashok.

Business People (e.g. Product Owner) define the "Why" and do the prioritization. Together you can define "What" and the Developer define the "How".

In general the purpose of User Stories are conversations (check Kent Beck, Ron Jeffries) and can be seen as pointer to the actual requirements (Mike Cohn). It doesn't matter what template you choose as long as it makes sense to your team (e.g. Gojko Adciz states in his book that they used images once).

I highly recommend you to take a look at


Designate a Product Owner and participate in refining the stories

Based on some of your description, it looks like you do not have a designated Product Owner:

...work out the detail of stories with whatever business representatives are available...

Here is what the owner of the story actually desired...

According to the Scrum Guide:

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

Also, it looks like the development team is passively awaiting the "business representatives" to write-up the stories:

What level of detail\analysis should the team expect...

We have raised story quality at every retrospective for a long time...

Again according to the Scrum Guide:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

The development team should get fully familiar with the Product Vision and the business goals in the release plan and actively participate with the Product Owner to refine the stories.

As to how much effort to put into this effort, again the Scrum Guide says:

Refinement usually consumes no more than 10% of the capacity of the Development Team.

  • Thanks, unfortunately we are using DSDM Atern and not Scrum. Our BA is performing a sort of Product Owner role. I agree that the team should participate in refining but are you saying the stories can come into the backlog widthout a certain amount of understanding by Product Owner beforehand?
    – davy
    Commented Jan 26, 2015 at 18:30
  • The reason for having only one PO in Scrum has more to do with setting priorities on the stories than with fleshing out the story details. Commented Jan 27, 2015 at 11:47

The "stories" you provide as examples aren't user stories because they don't describe tangible changes. You have epics, which can be broken down into smaller stories that should follow INVEST principles.

Often this is the case of a PO or business representative that knows what they want, but are too lazy or don't have enough time to write it down. Instead they write an Epic that "invites" the developers to ask clarifying questions about their vision. Avoid this; it leads to confusion and constant scope change within the iteration.

As a Scrum Master I see this all the time and I ask dev teams that struggle with poor stories to do the following:

If its a story that impacts a UI, can the developer/tester visualize the impact of the story to the UI?

If its a backend story, does the developer/tester understand what data or framework needs to be moved/manipulated to make the story work? What is the right data? What makes the data timely?

If the dev team can answer these questions, but they aren't implicit in the story we have a discussion and ask the PO to split or rewrite the story to make these answers implicit. If they are unwilling to do this we go to option two:

Option 2: If the team can't answer the above questions at all I ask them to throw the "Epic" story point estimate (for my teams that's usually a 13 or a 21). The entire team has an agreement that we don't allow these size "stories" into an iteration and its a strong, empirical signal to the PO that he/she didn't do their part of the work. We then either cancel the iteration or prioritize these stories out of the iteration and swap them with other tangible work.


Unlike many I don't think that the examples not being ideally written user stories is a problem here. I mean, they don't precisely describe what is supposed to be built but I'm yet to see the scope of work that leaves no area for interpretation.

In fact, I consider sharing business goals in feature / story description is in my opinion a good thing as it allows the team to make informed decisions whenever they are about to make a choice.

The question was about the expected level of details though. A proxy answer would be: the team should get only as many details to be able to build what clients or stakeholders want.

It doesn't mean that all the details have to, or even should, be in a story. From my experience nothing beats good communication between the team and the client. I'd go as far to suggest that the discussion about the exact level of details or form of the stories may be futile.

Having a short chat on what is to be done between all interested parties will allow to:

  • Give developers enough relatedness to technical concepts they deal with
  • Explore edge cases that either party may be unaware of
  • Get on the same page on all the details that are not described in any version of the story
  • Explicitly discuss potential consequences of changing one feature in other part of the app

In other words I don't think that the level of details in the stories is a problem. We often go with even more general descriptions of features (we don't even care to use the user story format).

What is likely a problem here is a level of details covered in a discussion about stories or even insufficient communication around them. Conversations should be a natural tool to figure out all the details both before starting the work and once development is ongoing.

Also, the more direct the discussions are, i.e. with no proxy, the better. This means that ideally business analysis role is distributed across the team or the team can use help from such a person on demand whenever they're discussing work items with stakeholders.


The Scrum Master should be helping your Product Owner write the user stories, as the ones you have given seem to be almost specifying what the team should do. They shouldn't - it's up to the team to decide how the goal is reached.

A better user story, in my opinion, is "As an e-Commerce executive, I want to be able to know why callbacks were requested, so I can ensure we aren't calling customers at the wrong time". It doesn't describe how, it just defines what and why the user wants something.

The Cone of Uncertainty comes into play here - you don't know much to start with, and your backlog grooming should start to flesh out the details, both from a technical perspective as well as from a user perspective. The team gains clarity from the product owner by asking exactly the kind of questions you detail in your bullet points. Any assumptions and assertions are all recorded against the user story.

So, to answer your question: LOTS of analysis should be done, but by the team. The Product Owner may also need to research some more depending on the questions asked by the team.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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