Once all user stories are written down for functional requirements, we still need to define some other requirements as communication with a remote server or navigation. This whole process could be defined as As an user I want my information to be available in all of my devices or As an user I want an intuitive navigation so that I dont have to read a manual. But the work to be done is extensive enough to be captured in a single user story, which leads me to think that there is a structure for requirements like the following:

  • Create a communication interface to interact with server's API
  • Define a ui navigation structure

My question would be if how do you write down specifications that are not necessary user expectation of the system? Is there any kind of "Architectura user stories" or similar?

3 Answers 3


There are two answers to this, but let's start with the one that seems most applicable to the examples you've given:

Definition of Done

The Definition of Done is a checklist maintained by the team that can be applied to every user story. Often times, this includes things like unit test coverage, regression testing and code reviews. However, sometimes this is a good place to include architectural constraints. For example, you could have a checkbox in your Definition of Done that reads:

Any UI element renders properly in Firefox, Chrome, IE, as well as Apple and Android default mobile browsers.


Navigation elements have had hallway usability testing to ensure they are intuitive

Emergent Architectural Requirements

If you've broken down your user stories well, architectural requirements will emerge. For example, if I had a story like:

As a user, I would like to be able to view my points earned this month so that I can see my progress toward the next reward.

you could break that down into "As a desktop user" and "As a mobile user". This is the ideal approach because it gives you more choice and encourages more creative solutions. It's easier for the Product Owner to prioritize which features on which devices offer the most value. It also is more likely to result in solutions that are truly optimized for their device, not just copied. The downside is you have to be vigilant about making sure your stories are always broken down well and no one simply forgets and that if your technical practices aren't strong, you can box yourself into a lot of rework.

Don't forget that both options are available to you. Some might work better in your DoD while others will work better emerging out of user stories.


As an user I want an intuitive navigation so that I don't have to read a manual

Is not a good user story because it is difficult to define what that would look like. You would never want an unintuitive navigation so there doesn't seem to be any point in calling out an intuitive one.

Likely in this you need to drill down to the specific features that the Product Owner thinks the user desires.

As an user I want my information to be available in all of my devices.

This seems to be a valid user story, but you've already said it's too large. Therefore, you should break it down. Without knowing the product you're developing, I think you have to look at the types of information and the devices you support.

The minimum set of features you need to support is smaller than you think. You should spend some effort thinking how to incrementally deliver the feature.

What you describe as, "Architectural Stories" do not seem to fit with the typical way people define stories. They're problematic because they are, non-negotiable and depended on by other stories. The product owner cannot say the don't want them. See

See INVEST criteria for more information on what defines a good user story.


There are two ways to do that

You can break stories into tasks, sub-tasks Or You can add acceptance criteria to this story, where acceptance criteria is nothing but all the scenarios which developer has to cover during unit testing, so that all feature and task automatically gets completed under single user story

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.