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)?
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:
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.
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.
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;
- 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;
- non functional requirements;
- use cases;
- business rules;
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.
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.