In the last few months I spent a lot of time arguing about the role of technical considerations when developing user stories. In my point of view, a lot of stories are not really debatable without understanding and respecting the technical boundaries the solutions is developed in. Other people point out, that we should only debate the functional aspects but ignore technical considerations. I think the latter idea works great if the feature can be done without thinking about the technology - e.g. "as a user, i want to have a red button on my website".

But often, a feature is only possible because a certain technology is employed - e.g. when developing our new add-on feature we relieved heavily on docker which enabled us to let the user any programming language they want to developt their add-on. Without the docker technology, the feature would have looked totally different (and would have probably only supported a single language).

In my mind, there are two kinds of technologies: enabling technologies (If your feature touches an area where such a technology is used, you must discuss the technology, our your dicussion is problematic) and supporting technologies (soemthing you can replace at will, e.g. if you want to use json or xml).

What is your take in this topic? How to keep scrum user stories as open as possible without ignoring key technological ideas?

4 Answers 4


It's important to make a distinction here between a use case and a user story. A user story is a user-legible document describing the needs of a user in a program. It should be something that any other non-technician can read and understand to what it is referring. I found a decent article describing the differences here.

A use case is a technical version of a user story. It describes conditions which must be true first, it describes precise steps undertaken by the user, describes what the end effect is, and highlights all the technologies required to realize it.

In short, a user story is written by the user while a use case is written by the technician.

It would be incorrect for a user story to mention specific technologies as this should not be the scope of a user story. The point of a user story is to highlight what requirements the program must have from the point of view of a layman. Therefore you shouldn't see user stories like, "I enter windows, and then enter the bash prompt and type in my credentials .."

It should be more like, "Username and password is requested and he logs in.." Notice that this allows the possibility of a GUI interface as well as a prompt. What should be taken from this is that the program should authenticate the user, not that JavaFX should be used or that it should be installed on a Windows computer.

Should the unlikely case in which a user story requires a combination of technologies to realize that aren't compatible with one another, that and possible solutions to this problem should be evaluated afterwards. However, by the nature of a user story, it should not directly refer to technological requirements, whether it be enabling technologies or supporting technologies in my humble opinion.


This isn't an all-or-nothing thing. You must handle different technical platforms differently depending on the role they play in the story.

In your example, the user wants to operate a web site and not just use it. That means that by definition, they know what a web page is and something about how to produce one. You also say that they might want to use different programming languages to develop their site further, That means that the concept of programming languages is also a user concept, and it's okay to talk about it freely in a story without making it incomprehensible to users.

In the other hand, the fact that you are using virtualization to allow this to happen, and especially that you are going to use a particular technology to virtualize things, may be over the users' heads. Lots of people who can write HTML/CSS, or even people who can write Ruby/C/Python/what-have-you know little or nothing about virtualization. (Me, for instance.) Therefore, neither of those concepts belongs in a user story. There are plenty of other document types to discuss and document what you are actually doing in the implementation.


@Christian-Sauer The theoretical answer is that non-functional requirements are to be modeled as constraints on user stories, per this guidance from the Scaled Agile Framework website.

Mike Cohn covers this in Chapter 16 of User Stories Applied, where he illustrates how to add constraints to a paper-based story card.

enter image description here

Unfortunately, this doesn't work well in practice with large teams because the constraints aren't easily tracked in most agile requirements management tools.

In practice, I like to write user stories and acceptance criteria for these types of requirements, using the requesting system as the user in the story. Why? This approach forces the technical team to explain what "good" looks like, in a manner that is fully testable via well formed acceptance criteria.

The non-functional user stories can be linked to what I call "architecturally significant user stories," prioritized, and assigned for implementation during one or more sprints.

UPDATE: What makes a story architecturally significant?

A story is architecturally significant when implementation of the required business behavior impacts or stresses one or more non-functional constraints of a system.

Example: On a top 20 Internet Retailer website that caters to business customers, display of customers-specific pricing during search is an architecturally significant user story.

User story: As a Purchasing Agent, I want to see my discounted pricing during search so I can know I am getting the lowest contracted price before adding an item to my shopping cart.

Customer-specific pricing for B2B websites is very complex because a given customer may simultaneously participate in multiple contracts that have varying discount levels across product categories. Therefore, the ability for the end user to see the "lowest contracted price" during search is architecturally challenging. A large B2B website may contain hundreds of millions of customer-specific prices.

These prices must be accessible in less than 200 milliseconds if the search results are to be returned to the shopper's browser in less than 1 second. Implementing this user story early in a project allows the project team to verify whether the architecture of the application can deliver to the 200 millisecond constraint.

NFR Story: As the website presentation layer, I need the pricing component to return catalog and/or customer specific prices for a page of search results within 200 milliseconds so I can render a web page of search results for products within 500 milliseconds.

Acceptance Criteria: The acceptance criteria for a user story provide additional details about the story for the development team, explaining the conditions that must be present for the product owner to agree that the story has been fully implemented.

For a non-functional requirement, the acceptance criteria should describe how we would observe achievement of the requirement under various real world usage scenarios. Returning to our pricing service response time user story, here are some acceptance criteria for this story.

  1. Verify that the average response time to price a list of 16 products is less than or equal to 200 milliseconds.
  2. Verify that the average response time does not degrade by more than 5% when pricing larger groups of products, including 50, 100, and 200 products.
  3. Verify that the 95%-ile in response time is within 20 milliseconds of its average.
  4. Verify that the average and 95%-ile response time goals are met when the pricing service handles requests at the following volumes: 100 requests / second, 500 requests / second, 1,000 requests / second.
  5. Verify that the average and 95%-ile response time goals are met when the pricing service must price from product data that includes the following numbers of customer-specific and program prices: 10,000,000, 50,000,000, 100,000,000, and 150,000,000.
  6. Verify that the average and 95%-ile response time goals are met when the pricing service must price a mix of products including catalog pricing, standard discount pricing, and customer-specific pricing where the customer qualifies for pricing on multiple contracts (e.g. State of Colorado, Colorado University System, and Western States Contracting Alliance).

I encourage my engineering leads to schedule architecturally significant stories early in projects so we can find potential problems in the architecture as soon as possible, because this gives the team more time to solve the problems than when the hard parts are deferred to program increments / sprints later in the delivery cycle.

  • Thx! Can you elaborate what "architecturally significant user stories," are and how you use them? Nov 24, 2017 at 12:48
  • @Christian-Sauer Sure. I'll edit the post and elaborate. Would you please upvote my answer if it was helpful?
    – Len Greski
    Nov 24, 2017 at 13:18

I Agree technical consideration should not play any part in the user stories in any field.

Still, there are few things which gets involved here and one of them is cost.

If you directly proportionate the cost with user stories then yes technical consideration should be considered. You need take each perspective for your scope.

It varies to cases, you can't be precise to define a procedure.

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