In Scrum, are stories and acceptance criteria supposed to be a replacement for project scope and product requirements? Is it convenient that all requirements are scattered over many issues in Jira (instead of being kept in a single document)?

6 Answers 6


In Scrum, are stories supposed to be a replacement for product requirements?

No, they are not.

One of the Agile values is "Working software over comprehensive documentation". One reason being that it's hard to define what the product should do from the beginning. Once the clients see the software, they will want changes because they get a better understanding of what they need once they see the software working. That's also why you build software in short iterations: to get feedback quickly and make sure you build the right thing.

In this context, starting software development with a large software requirements document doesn't really make sense. But if you don't have a full specification document, you still need something as the basis of your developments, and user stories are a better tool for this environment. They are just a "placeholder" for the discussions you need to have about what exactly you need to build.

See the following links for more details:

  • But we could incrementally build requirements just the same way we incrementally build a product. Any developer could use these reqs to recap something or to make sure his current work is consistent with the already implemented functionality (instead of asking the other developers or searching the closed story or task). Commented Dec 27, 2019 at 19:38
  • 4
    You could, but the question is "should you?" Working software is more important than having everything documented in detail. When the Product Owner accepts an increment, it means the software does what it's supposed to do. If you are worried that later someone might break something, they can talk to the Product Owner. Having detailed requirements written down will help answer such doubts, but how often do you expect this to happen? At which point do the detailed requirements move from useful to wasteful? Often, extensive documentation is waste.
    – Bogdan
    Commented Dec 27, 2019 at 20:23
  • 2
    @Bogdan, my experience is that requirements tend to become useful five years later when you need to know whether you can change this or somebody depends on it and all the people who worked on that feature have long left the company.
    – Jan Hudec
    Commented Dec 28, 2019 at 22:59
  • 1
    @JanHudec: My experience has been different. The code and the documentation get out of sync. Code does one thing, documentation says another. It takes discipline to always change one when you change the other, so the two tend to drift. When that happens you tend to favor the code because at least the code has been in use for the last five years with nobody complaining it's wrong, while the documentation has been sitting on a shelf unread.
    – Bogdan
    Commented Dec 29, 2019 at 7:21
  • 1
    @Bogdan, it depends very much on the domain. It is also the case where the task-tracker is actually the right place to put the documentation in; if it can link the changes to the task, as most can these days, you can look at the history of the code, get the tickets it was changed under and if you wrote down the reasons there (not necessarily before starting the work, may be as the product owner comments came in during it), it will pay off.
    – Jan Hudec
    Commented Dec 29, 2019 at 9:10

Before I begin the answer, I'd like to point out that user stories are not part of Scrum. They are not mentioned in the Scrum Guide, but Scrum Teams commonly use them as Product Backlog Items. In Scrum, the Product Backlog and its Product Backlog Items are "the single source of requirements for any changes to be made to the product". The Product Owner is responsible for capturing work as Product Backlog Items, so they are ultimately responsible for determining what is in or out of scope for the product.

So, to get to the question asked: Yes and no. User stories and their acceptance criteria are used much like requirements. If you are using user stories, you most likely won't create and maintain a traditional requirements specification as well.

Both user stories and traditional requirements are a way to capture what the system is supposed to do or enable a user to do. User stories take on many of the same characteristics as good requirements - cohesive, consistent, atomic, verifiable, have specified importance, and are traceable to some user or market need.

User story cards are just the start of the conversation, though. The story is refined and acceptance criteria are developed through a collaborative process between the development team and stakeholders.

Ultimately, I would say that the developed test cases are the final specification that evolves with the system. If you develop the test cases before developing the system, you can use the test cases as requirements. Otherwise, the passing tests would be an as-built specification of the system. You can capture not only behavior and functional requirements in test cases, but many quality attributes of a system can also be captured in test cases - performance, scalability, throughput can be tested with automated tests. Other quality attributes can be confirmed by inspection or test as well. A test that can not be successfully executed means that either the requirement is out-of-date and needs to be removed or updated or that the system no longer meets requirements.

  • But stories in Jira are not organized in groups, they often have vague titles. It is a mess. And when developers implement new complex feature they spend a lot of time on research of the already implemented functionality (by the other developers or even by themselves sometime ago). Commented Dec 28, 2019 at 8:03
  • You can have epics or labels to organize tickets Commented Dec 28, 2019 at 8:32
  • @ChrisBrettini Adrian is right about organization - Epics (at least in Jira) are used to form a hierarchy. Labels are also a good way. Capturing test cases in Jira and linking automated tests to those test cases and applying labels to those test cases can also help organize your requirements. The choice of title is up to you - personally, I've seen this and worked with teams to write better titles to help with automatic release notes generation, but it can also help with general organization.
    – Thomas Owens
    Commented Dec 28, 2019 at 10:49
  • I'd also add, if you're using Jira, you really should look at using Confluence as well. The ability to extract tickets from Jira to Confluence pages and snapshot Confluence pages as PDF can help provide "documents" that are easier to maintain, and you can get plugins to add capabilities to both sides.
    – Thomas Owens
    Commented Dec 28, 2019 at 10:51

In Scrum, are stories and acceptance criteria supposed to be a replacement for project scope and product requirements?

Scrum does not specify the format of requirements other than that they should be in a product backlog that is an ordered list of everything that is known to be needed in the product.

The reason that user stories are popular with teams that use the Scrum framework is that they work well when you are trying to be good at responding to change.

The concern with traditional scope documents and product requirements is that they may constrain change. This is because:

  • Detailing extensive requirements up front can result in a reluctance to accept change as so much time and energy has already been invested in the requirements
  • A comprehensive set of requirements is more likely to become out of date and so will need to be constantly maintained
  • Comprehensive documentation can lead to a false sense of confidence - product development often has an element of requirements discovery

Is it convenient that all requirements are scattered over many issues in Jira (instead of being kept in a single document)?

That is a question for your Scrum team to answer. If they don't find it convenient then they should try another approach. There is nothing to say you have to work with user stories or that you should never use a requirements specification.

I have worked with business analysts that have managed to combine an overview document with user stories in JIRA. They retain the traditional user story format, but use links in each JIRA ticket to a wiki document on Confluence that gives a more cohesive view of the product.

  • Thank you! Aren't stories likely to become out of date too (and will need to be constantly maintained)? Commented Dec 28, 2019 at 14:45
  • As user stories are typically just a sentence or two they tend to have a longer shelf life than a detailed requirement. This is one of the reasons we try not to add detail to a user story (like acceptance criteria) until close to the time we plan to do the work. This is one of the key benefits of user stories. Commented Dec 28, 2019 at 18:20
  • Sometimes a couple of years down the road it might be the lack of requirements that stifles change though—when you want to change something and can't find whether it was done this way by design or coincidence and the original developers are no longer in the company and can't be consulted, or simply don't remember anyway.
    – Jan Hudec
    Commented Dec 28, 2019 at 23:04
  • Possibly. Agile is about favouring responding to change over following a plan. When you follow that approach you get benefits but as with everything there is also a downside. It is for each organisation and each team to determine if the benefits outweigh the disadvantages. Commented Dec 29, 2019 at 9:31
  • @BarnabyGolden, well, what your successor will need in a couple of years is record of the reasons behind the choices you are taking. That does not mean you need to be following a set plan. It just means you should add explanation for why you did the work the way you did to the stories or the commit logs so they can be found next time the code needs to change.
    – Jan Hudec
    Commented Dec 29, 2019 at 19:18

Scrum doesn't require use of "user stories", but is a common practice

The Scrum Guide (https://www.scrumguides.org/) does not mention user stories at all. Using Scrum you can choose any way to represent the expected behavior of the software:

  • user stories;
  • use cases;
  • storyboards;
  • wireframes;
  • BPMN fluxograms;
  • data flow diagrams;
  • UML; or
  • any other.

Many tutorials and courses teach user stories as the primary form of describing backlog items and many planning software packages adopted user stories. Personally, I think user stories are not that useful, but this is not a problem on Scrum and I will explain why ahead, bear with me. In Scrum, are stories supposed to be a replacement for product requirements?

User stories doesn't replace the full set of requirements of RUP, but this is not necessary and you are not limited to user stories

On RUP, "requirements" was the discipline where the stakeholders was interviewed to describe that they want and a set of documents such as:

  • stakeholder requests;
  • vision;
  • non functional requirements;
  • use cases;
  • business rules;
  • etc.

On RUP the requirements are almost like a contract that the development team must fulfill. On Scrum there is no such thing. The stakeholders are listened, but have no direct authority to define what the product will be.

On the document side of things, Scrum Teams are not limited to user stories. In a real project it is normal to find attachments in the user stories that better describes the ideas.

I actually write a lot of supporting material for my team. Before committing resources to develop new features or apps, I usually do a comprehensive study which results in several pages long documents, lots of diagrams and exploratory prototypes. On my work experience is more difficult to understand what is needed than actually building it. I pass much more time studying the business than coding.

There is no spoon"scope" in Scrum

PMI.org defines the project scope as the work required to output a project's deliverable with defined time and budget. In other words, a well defined specification and plan. Such model is more suited if the problem and solution are well defined and use well known technologies that have predictable results. But innovation, research and development doesn't work like that: not even the problem is well defined. For those a empirical model like Scrum is usually more effective.

According to the Scrum Guide, the Product Backlog:

  • is never complete;
  • is dynamic;
  • it constantly change.

Is normal and expected for many Product Backlog Items to be drooped and new ones be added every month. A Product Backlog that does not change over time is actually a symptom of a team that did not embraced the values of Scrum:

  • is not learning with experience;
  • is not taking advantage of opportunities;
  • is not adapting to the changes in the market.

Those kinds of teams usually loose a lot of opportunities of easier development that can add great value to the product. Of course, there are exceptions, but in my experience a backlog that doesn't change in a long time predicts failure or poor results.

Since the backlog is ever changing, there is no "scope", no baseline. Therefore, metrics like quantity or percentage of backlog items delivered have absolutely no meaning. The main metric of Scrum should be the value added to the product. And Scrum predicts constant reevaluation of the product value through the Scrum Reviews.

About the organization of the backlog on a issuer tracker platform

It is ok to create the backlog items as issues as long as you can present them as lists ordered by the priorities. I have no experience with Jira, but with Jazz Team Server and Kanboard and it worked fine to me. It was not good, but was enough.

Scrum can tolerate very incomplete and superficial requirement description

The Scrum Team can't escape the responsibility and repercussions of an unacceptable or low value product by stating that:

  • they delivered a high percentage of the backlog;

  • they meet the acceptance criteria of the user stories;

  • they build what the stakeholders asked them to.

The Scrum Guide emphasize the Scrum Review as an "informal meeting" designed to get the collaboration of stakeholders. This mean that the stakeholder requests, needs and ideas are informal ones. They are important, but is the responsibility of the Scrum Team to use those requests, needs and ideas as inspiration to identify what can add value to the product. The stakeholders can't be blamed in any way if their have a bad idea in an informal brainstorming section.

Since the Scrum Team is responsible by the "value" of the product, the team must be able to discuss the product increments in terms of value. The management must require the Scrum Team to talk business on the Scrum Reviews.

When the team must talk about the "value" of the product increment, the form and completeness of written requirements in the product backlog items becomes less and less important.

  • 1
    Actually, even product/projects using scrum have a scope. The scope is the broad idea for the product and it can be used to evaluate if a suggestion is worth it to be included in the product. E.g., adding photoshop-like image editing will probably be shot down if you are building a word processor. Commented Dec 29, 2019 at 19:26
  • Not according to the Scrum Guide: There is scope/goal control, but only over the sprint, not over the project. At the end of each sprint the project is reevaluated without any such restrictions: the "rule" is to add value. Is not uncommon that a development team researching answers to a problem ends finding a great and possible profitable solution to other problems. In this case it may be appropriated to go outside the initial expectations for the project. Yes, it is a bold move, is not easy, but sometimes pays off.
    – Lucas
    Commented Dec 30, 2019 at 8:38
  • Besides the Scrum Guide, you also need a dose of common sense. The scope I refer to is used to determine what makes it onto the product backlog in the fist place. So, it is involved before Scrum has a say in it. Commented Dec 30, 2019 at 18:16
  • Yes, the team must have goals and filter what goes on the product backlog accordingly. But I call that "focus".
    – Lucas
    Commented Dec 30, 2019 at 20:47

User stories are designed to be brief for a reason. They have been called promises to have a discussion between the dev team and product owner. Basically, we want to facilitate open communication and collaboration between the people with the vision for the product and the people who are designing the best possible solution to deliver the value they need. Agile values customer collaboration and constant communication with our business partners because without that we lose the ability to be flexible, and we end up with developers mechanically churning out code exactly as requested without any critical thinking or innovation (which is often not the best way to do it and won't solve the problems they have, wasting a lot of time, effort, and money)


I'm working in a long-running project with more than 10.000 jira tickets. It is definitely not convenient to have only jira as the source of documentation, but at least the tickets all have their dates.

More waterfall-style projects with a similar scope and duration had the original requirements doc, plus supplementals for which handled subsequent releases as their own mini-project. Some summary files and the test case descriptions were the only ones which got properly updated.

Both relied on human minds to know that an original requirement somebody might talk about had been altered by subsequent requests. The alternative would be to keep a comprehensive requirements document current, spending effort that needs to be defended in budget sessions.

  • 1
    Did I get you right that updating requirements document required a lot efforts? Could you explain what was the problem to update it? Commented Dec 28, 2019 at 8:18
  • @ChrisBrettini, someone comes and says "I want that widget over there green, not red. No idea who specified it red and when, just do it." After a couple of releases handled like that, catching up would be difficult.
    – o.m.
    Commented Dec 28, 2019 at 17:37

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.