Vjylku

How can I differentiate duration vs starting time

smartctl reports overall health test as passed but the tests failed?

Can you say "leftside right"?

Buying a "Used" Router

Was Opportunity's last message to Earth "My battery is low and it's getting dark"?

I have trouble understanding this fallacy: "If A, then B. Therefore if not-B, then not-A."

Identical projects by students at two different colleges: still plagiarism?

Players preemptively rolling, even though their rolls are useless or are checking the wrong skills

Why don't you get burned by the wood benches in a sauna?

Was there a pre-determined arrangement for the division of Germany in case it surrendered before any Soviet forces entered its territory?

Is it really OK to use "because of"?

Is Screenshot Time-tracking Common?

Sticky Strike or Sticky Delta

what is the required document in Agile

Does red noise even at low values mean a hardware problem with my camera's sensor?

Putting a vertical line in each Histogram using GraphicsGrid

In the Lost in Space intro why was Dr. Smith actor listed as a special guest star?

Calculating the strength of an ionic bond that contains poly-atomic ions

Boss asked me to sign a resignation paper without a date on it along with my new contract

Did ancient Germans take pride in leaving the land untouched?

Crack the bank account's password!

How can I handle players killing my NPC outside of combat?

What are some idioms that means something along the lines of "switching it up every day to not do the same thing over and over"?

Can I use a single resistor for multiple LED with different +ve sources?

what is the required document in Agile

What are some agile (scrum) metrics?Analysis document in ScrumSatisfying an external auditor when using AgileWhat are alternative agile applications?Is there any place for the Prince 2 Mandate Document 'Quality Expectations' in an agile development?What are some Agile Testing Estimation Techniques?what should I do to overcome the agile process related issues in my organization?Organizing testing in a Scrum(ish) development projectIs the “definition of done” required in Scrum?What is an Agile “Reflection?”

1

Good day dears, i am confused about documentation in Agile as below

we try to implement Scrum in our company, the problem we faced is our traditional thinking which always requires physical document, My manager always asking me about Business Requirements Specification (BRS) and Software Requirements Specification(SRS)

is it a valid habit to writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?

if it is yes, can you supply me with any template? what is the ISO standard related to Agile documentation? we use TFS project management, any suggestion about the problem

thanks.

scrum

share|improve this question

asked 53 mins ago

user35136user35136

61

New contributor

user35136 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment | 

1

Good day dears, i am confused about documentation in Agile as below

we try to implement Scrum in our company, the problem we faced is our traditional thinking which always requires physical document, My manager always asking me about Business Requirements Specification (BRS) and Software Requirements Specification(SRS)

is it a valid habit to writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?

if it is yes, can you supply me with any template? what is the ISO standard related to Agile documentation? we use TFS project management, any suggestion about the problem

thanks.

scrum

share|improve this question

asked 53 mins ago

user35136user35136

61

New contributor

user35136 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a comment | 

Good day dears, i am confused about documentation in Agile as below

we try to implement Scrum in our company, the problem we faced is our traditional thinking which always requires physical document, My manager always asking me about Business Requirements Specification (BRS) and Software Requirements Specification(SRS)

is it a valid habit to writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?

if it is yes, can you supply me with any template? what is the ISO standard related to Agile documentation? we use TFS project management, any suggestion about the problem

thanks.

scrum

share|improve this question

asked 53 mins ago

user35136user35136

61

New contributor

user35136 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

share|improve this question

asked 53 mins ago

user35136user35136

61

New contributor

user35136 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

share|improve this question

asked 53 mins ago

user35136user35136

61

New contributor

user35136 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

asked 53 mins ago

user35136user35136

61

New contributor

user35136 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

asked 53 mins ago

user35136user35136

61

2 Answers
2

active

oldest

votes

1

In the manifesto for Agile software development one can read:

Working software over comprehensive documentation

This doesn't mean documentation is a bad thing. Instead, working code is better so you can document what you are going to code.

That being said, user stories and acceptance criteria might be all you need to understand the requirements, considering you're not responsible for the Vision and Scope Document.

share|improve this answer

answered 40 mins ago

Tiago Martins PeresTiago Martins Peres

4811418

add a comment | 

1

I encourage people not to think of user stories (or backlog items of any kind) as another form of requirements. There is a critical difference in thinking between the use of requirements documents and backlogs that teams and organizations need to understand in order to effectively use the latter. Backlogs are emergent. This means that they not only change over time (there's nothing stopping a BRS from changing) but that later backlog items build on and modify earlier items such that it is possible that the earlier items no longer describe the application's behavior.

This means that the documentation you require will largely be separate from your requirements (think of it as what you walked into development knowing vs what you did in development). Note that things like ISO 9001 is mostly about validating that you follow your processes (whatever those happen to be) and that you record information you will need to audit or maintain the software later. The days where documentation and audit standards were about making sure the result matched the original idea perfectly are largely gone. The only place I see that anymore is places where they have it written into their processes and don't want to change the documented processes, in which case it's a conscious choice, not a constraint.

share|improve this answer

answered 24 mins ago

DanielDaniel

8,60921125

add a comment | 

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "208"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

user35136 is a new contributor. Be nice, and check out our Code of Conduct.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25875%2fwhat-is-the-required-document-in-agile%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

1

In the manifesto for Agile software development one can read:

Working software over comprehensive documentation

This doesn't mean documentation is a bad thing. Instead, working code is better so you can document what you are going to code.

That being said, user stories and acceptance criteria might be all you need to understand the requirements, considering you're not responsible for the Vision and Scope Document.

share|improve this answer

answered 40 mins ago

Tiago Martins PeresTiago Martins Peres

4811418

add a comment | 

1

In the manifesto for Agile software development one can read:

Working software over comprehensive documentation

This doesn't mean documentation is a bad thing. Instead, working code is better so you can document what you are going to code.

That being said, user stories and acceptance criteria might be all you need to understand the requirements, considering you're not responsible for the Vision and Scope Document.

share|improve this answer

answered 40 mins ago

Tiago Martins PeresTiago Martins Peres

4811418

add a comment | 

In the manifesto for Agile software development one can read:

Working software over comprehensive documentation

This doesn't mean documentation is a bad thing. Instead, working code is better so you can document what you are going to code.

That being said, user stories and acceptance criteria might be all you need to understand the requirements, considering you're not responsible for the Vision and Scope Document.

share|improve this answer

answered 40 mins ago

Tiago Martins PeresTiago Martins Peres

4811418

share|improve this answer

answered 40 mins ago

Tiago Martins PeresTiago Martins Peres

4811418

answered 40 mins ago

Tiago Martins PeresTiago Martins Peres

4811418

answered 40 mins ago

Tiago Martins PeresTiago Martins Peres

4811418

1

I encourage people not to think of user stories (or backlog items of any kind) as another form of requirements. There is a critical difference in thinking between the use of requirements documents and backlogs that teams and organizations need to understand in order to effectively use the latter. Backlogs are emergent. This means that they not only change over time (there's nothing stopping a BRS from changing) but that later backlog items build on and modify earlier items such that it is possible that the earlier items no longer describe the application's behavior.

This means that the documentation you require will largely be separate from your requirements (think of it as what you walked into development knowing vs what you did in development). Note that things like ISO 9001 is mostly about validating that you follow your processes (whatever those happen to be) and that you record information you will need to audit or maintain the software later. The days where documentation and audit standards were about making sure the result matched the original idea perfectly are largely gone. The only place I see that anymore is places where they have it written into their processes and don't want to change the documented processes, in which case it's a conscious choice, not a constraint.

share|improve this answer

answered 24 mins ago

DanielDaniel

8,60921125

add a comment | 

1

I encourage people not to think of user stories (or backlog items of any kind) as another form of requirements. There is a critical difference in thinking between the use of requirements documents and backlogs that teams and organizations need to understand in order to effectively use the latter. Backlogs are emergent. This means that they not only change over time (there's nothing stopping a BRS from changing) but that later backlog items build on and modify earlier items such that it is possible that the earlier items no longer describe the application's behavior.

This means that the documentation you require will largely be separate from your requirements (think of it as what you walked into development knowing vs what you did in development). Note that things like ISO 9001 is mostly about validating that you follow your processes (whatever those happen to be) and that you record information you will need to audit or maintain the software later. The days where documentation and audit standards were about making sure the result matched the original idea perfectly are largely gone. The only place I see that anymore is places where they have it written into their processes and don't want to change the documented processes, in which case it's a conscious choice, not a constraint.

share|improve this answer

answered 24 mins ago

DanielDaniel

8,60921125

add a comment | 

I encourage people not to think of user stories (or backlog items of any kind) as another form of requirements. There is a critical difference in thinking between the use of requirements documents and backlogs that teams and organizations need to understand in order to effectively use the latter. Backlogs are emergent. This means that they not only change over time (there's nothing stopping a BRS from changing) but that later backlog items build on and modify earlier items such that it is possible that the earlier items no longer describe the application's behavior.

This means that the documentation you require will largely be separate from your requirements (think of it as what you walked into development knowing vs what you did in development). Note that things like ISO 9001 is mostly about validating that you follow your processes (whatever those happen to be) and that you record information you will need to audit or maintain the software later. The days where documentation and audit standards were about making sure the result matched the original idea perfectly are largely gone. The only place I see that anymore is places where they have it written into their processes and don't want to change the documented processes, in which case it's a conscious choice, not a constraint.

share|improve this answer

answered 24 mins ago

DanielDaniel

8,60921125

share|improve this answer

answered 24 mins ago

DanielDaniel

8,60921125

answered 24 mins ago

DanielDaniel

8,60921125

answered 24 mins ago

DanielDaniel

8,60921125