Requirements Gathering in SCRUM. Acceptable to talk about High Level requirements in first sprint?

Question

In Scrum at what stage the requirements are gathered?

I am writing a report about my project but I am having trouble deciding where to put the High Level requirements.

I am thinking of having a section called Sprint 0. Where I have sub headings

• Analysis
• Design
• Implementation
• Testing
• Evaluation

and in the analysis I talk about all the requirements gathered so far meaning an overview of what the system must do.

The other option is to have a section called product backlog where I analyse the problem and write the requirements that were gathered in the meeting with the client.

What is the ideal approach to this?

Answer 1

In Scrum, requirements go in user stories. The product owner is responsible for talking to all of the stakeholders and gathering requirements. There is generally no single requirements document at all, nor any overall project report similar to what you describe.

A user story will describe the requirement at the highest level with a single feature with a regularized format. "As a $X I want to $Y so I can $Z". For example:

"As a legally-blind user I can magnify my screen so I can see small screen elements"

That's the high level description that goes on your sticky notes (physical, or metaphorical in a tool like Rally.) After this, you would generally put more detailed descriptions and then finally the "Acceptance Criteria". The Acceptance Criteria are the actual concrete requirements. Usually I write this as a bulleted list and these are the things that must be true for the store to be considered complete.

In theory with agile, you don't create reports with "what the system must do". Instead, you, as the Product Owner, take all stories and put them in priority. Then, when the sprint starts, the team will point those stories, and take the ones into the sprint that will fit and work at them.

At the end of the sprint, you show the stakeholders what is done, write any new stories that need to be written and repeat. You release to the public whenever the stakeholders think the software is ready to release.

It is perfectly fine for stakeholders to say they need a certain set of things to release, but that just means those things are on the stake. The whole point of Agile is that these things can be changed during the process, between sprints. That means that talking too much about the final project goes against the grain of what Agile as about. As such, a report you are describing isn't something that would ever been done on an Agile project.

I am product owner a team using Scrum, and what our long-term documents look like are generally lists of stories I describe. There has never been a single document describing design. Instead, we have various places where stakeholders list the features they want to see in the next release in both our PM software and a wiki-like system. These are living documents, often changing up to a sprint before the release.

As a product owner, I am always gathering requirements. The point of Agile and Scrum is that requirements change. If you collect requirements at a particular "stage" your requirements will be stale when you release, and it therefore won't meet the needs of the stakeholders.

To summarize, in Scrum:

• There is no single document describing the project written at the start.
• There are many living documents encapsulating the current requirements
• There is no particular stage when requirements are gathered
• Requirements are always being gathered for the next sprint's planning
• You won't know for sure what the actual requirements to release are until the point where the stake holders say the software is good to release