Where does documentation like business and software requirement spec docs fit in an agile project?












2















We are implementing scrum in our company. The problem we faced is our traditional thinking, which always requires physical document.



Management is constantly asking for documents like Business Requirements Specification (BRS) and Software Requirements Specification(SRS).



When moving towards agile, is it ok writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?



If that's the case, can you supply me with templates or examples? Is there something like an ISO standard related to Agile documentation?



We use TFS for project management.










share|improve this question









New contributor




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
















  • 2





    If your company has an existing workflow that uses BRS and SRS then you should find out how those documents are used. What purposes are they serving? Who reads them and what do they do with them? Talk to the consumers of these documents about what they would need and if they feel your user stories would satisfy these needs.

    – Pace
    8 hours ago











  • Good i will,based on your experience, as a development team, can we implement the code based on user story bounded with acceptance criteria.In our current model the SRS feed into development team and testing team use the same document to verify the developed feature

    – Mjd Kassem
    8 hours ago


















2















We are implementing scrum in our company. The problem we faced is our traditional thinking, which always requires physical document.



Management is constantly asking for documents like Business Requirements Specification (BRS) and Software Requirements Specification(SRS).



When moving towards agile, is it ok writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?



If that's the case, can you supply me with templates or examples? Is there something like an ISO standard related to Agile documentation?



We use TFS for project management.










share|improve this question









New contributor




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
















  • 2





    If your company has an existing workflow that uses BRS and SRS then you should find out how those documents are used. What purposes are they serving? Who reads them and what do they do with them? Talk to the consumers of these documents about what they would need and if they feel your user stories would satisfy these needs.

    – Pace
    8 hours ago











  • Good i will,based on your experience, as a development team, can we implement the code based on user story bounded with acceptance criteria.In our current model the SRS feed into development team and testing team use the same document to verify the developed feature

    – Mjd Kassem
    8 hours ago
















2












2








2








We are implementing scrum in our company. The problem we faced is our traditional thinking, which always requires physical document.



Management is constantly asking for documents like Business Requirements Specification (BRS) and Software Requirements Specification(SRS).



When moving towards agile, is it ok writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?



If that's the case, can you supply me with templates or examples? Is there something like an ISO standard related to Agile documentation?



We use TFS for project management.










share|improve this question









New contributor




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












We are implementing scrum in our company. The problem we faced is our traditional thinking, which always requires physical document.



Management is constantly asking for documents like Business Requirements Specification (BRS) and Software Requirements Specification(SRS).



When moving towards agile, is it ok writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?



If that's the case, can you supply me with templates or examples? Is there something like an ISO standard related to Agile documentation?



We use TFS for project management.







scrum agile documentation






share|improve this question









New contributor




Mjd Kassem 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









New contributor




Mjd Kassem 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




share|improve this question








edited 8 hours ago









Tiago Cardoso

5,33231852




5,33231852






New contributor




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









asked 9 hours ago









Mjd KassemMjd Kassem

111




111




New contributor




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





New contributor





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






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








  • 2





    If your company has an existing workflow that uses BRS and SRS then you should find out how those documents are used. What purposes are they serving? Who reads them and what do they do with them? Talk to the consumers of these documents about what they would need and if they feel your user stories would satisfy these needs.

    – Pace
    8 hours ago











  • Good i will,based on your experience, as a development team, can we implement the code based on user story bounded with acceptance criteria.In our current model the SRS feed into development team and testing team use the same document to verify the developed feature

    – Mjd Kassem
    8 hours ago
















  • 2





    If your company has an existing workflow that uses BRS and SRS then you should find out how those documents are used. What purposes are they serving? Who reads them and what do they do with them? Talk to the consumers of these documents about what they would need and if they feel your user stories would satisfy these needs.

    – Pace
    8 hours ago











  • Good i will,based on your experience, as a development team, can we implement the code based on user story bounded with acceptance criteria.In our current model the SRS feed into development team and testing team use the same document to verify the developed feature

    – Mjd Kassem
    8 hours ago










2




2





If your company has an existing workflow that uses BRS and SRS then you should find out how those documents are used. What purposes are they serving? Who reads them and what do they do with them? Talk to the consumers of these documents about what they would need and if they feel your user stories would satisfy these needs.

– Pace
8 hours ago





If your company has an existing workflow that uses BRS and SRS then you should find out how those documents are used. What purposes are they serving? Who reads them and what do they do with them? Talk to the consumers of these documents about what they would need and if they feel your user stories would satisfy these needs.

– Pace
8 hours ago













Good i will,based on your experience, as a development team, can we implement the code based on user story bounded with acceptance criteria.In our current model the SRS feed into development team and testing team use the same document to verify the developed feature

– Mjd Kassem
8 hours ago







Good i will,based on your experience, as a development team, can we implement the code based on user story bounded with acceptance criteria.In our current model the SRS feed into development team and testing team use the same document to verify the developed feature

– Mjd Kassem
8 hours ago












3 Answers
3






active

oldest

votes


















7














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



















  • 3





    A lot of people forget that the Manifesto lists eight important values, not four. The Manifesto makes a relative value judgement that the values on the left are more important than the values on the right, but it does not say that the values on the right are not important. The Manifesto explicitly says: "there is value in the items on the right". +1 for pointing that out!

    – Jörg W Mittag
    4 hours ago



















4














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.



Adding this section to respond to the comment:



Agile and Scrum can be confusing to adopt because there are a lot of good practices that people have come up with that have been lumped into Agile and Scrum, while at the same time, many of the core practices and principles get left out.



Agile: Agile is just values statements and principles. You can find them at https://agilemanifesto.org/. You can't really practice Agile - rather, your practices can be more or less Agile (as an adjective) depending on how well aligned they are with these values and principles.



Scrum: You can follow Scrum practices. Scrum is a lightweight framework, meaning it gives a number of events, artifacts, roles, and practices, but there's a lot of space to fill in how you do the work and what that work looks like. You can find the latest version of the Scrum Guides at https://www.scrumguides.org/scrum-guide.html. It is probably worth noting that if many teams pick and choose what to follow out of Scrum. While that isn't inherently wrong, it is designed to work as a whole and many benefits are lost when you start dropping practices.



XP: You didn't mention this, but a lot of practices common in Scrum that aren't specifically listed in the Scrum Guide (like User Stories) are actually from XP. XP is a lot more prescriptive on how to do the work. There's a pretty big change curve with adopting XP and I don't see many teams do it, but when Scrum started, they were often assuming that XP was going to fill some of the how-to space in their framework, so it's always worth looking at. http://www.extremeprogramming.org/ is a good place to start, if a bit clunky.






share|improve this answer


























  • Seconding this. The ISO rules simply say you need a well defined process. If your company decides that process includes SRS and BRS then your company needs to define how, if at all, the agile processes generate those documents. If your company decides that user stories will be the SRS or BRS then simply write that down as your process and follow it to make ISO happy.

    – Pace
    8 hours ago











  • you mean that is no Agile-Specific ISO, How do I ensure that I follow Agile? many per attempts tended to be waterfall, sorry it seem to be another question.

    – Mjd Kassem
    8 hours ago











  • I added a bit more to respond to the "following Agile" question. I hope that helps.

    – Daniel
    7 hours ago



















0














Customer-side BA here, currently in the middle of a large-scale enterprise data warehousing and infrastructure modernization initiative. The project teams use Jira instead of TFS, and though the concepts are the same, our use of the platform is mainly as an tracking and reporting tool interface with the core Agile team. The focus of our user stories are mainly to discuss and track testing, enhancement requirements, defect reporting - all of the type of feedback that comes "after the fact" of each sprint's work-product, so to speak, and well after the initial requirements have been published.



Key commentary on the BRS/SRS specification - these should be solicited from end-users in the planning/prototyping phase in order to prioritize architecture development and to develop the overall project plan; user stories, on the other hand, tend to be more focused on responding to feedback over particular channels, services, domains, or templates that arise after consumers have conducted feasibility and gaps analysis against the prototyped release.



In short - while the exact purpose of each document will vary across different organizations and projects, the requirements documentation and user stores are ultimately apples-to-oranges, however all three could feasibly be combined in the same basket of fruit. Emphasis on the role of each should be tailored to the interests of the group(s) driving the initiative.



End-users will set their requirements ahead of time and independently of the work being done in each sprint; they will likewise continuously adjust their plan in alignment with BA/DevOps feedback along the way - this communication gets relayed through the user stories during development as a tracking bulletin of sorts. The three are complimentary, but oftentimes they'll serve to document the interests and needs or distinctly different shareholder groups.






share|improve this answer








New contributor




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




















    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
    });


    }
    });






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










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25875%2fwhere-does-documentation-like-business-and-software-requirement-spec-docs-fit-in%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    7














    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



















    • 3





      A lot of people forget that the Manifesto lists eight important values, not four. The Manifesto makes a relative value judgement that the values on the left are more important than the values on the right, but it does not say that the values on the right are not important. The Manifesto explicitly says: "there is value in the items on the right". +1 for pointing that out!

      – Jörg W Mittag
      4 hours ago
















    7














    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



















    • 3





      A lot of people forget that the Manifesto lists eight important values, not four. The Manifesto makes a relative value judgement that the values on the left are more important than the values on the right, but it does not say that the values on the right are not important. The Manifesto explicitly says: "there is value in the items on the right". +1 for pointing that out!

      – Jörg W Mittag
      4 hours ago














    7












    7








    7







    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













    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












    share|improve this answer



    share|improve this answer










    answered 9 hours ago









    Tiago Martins PeresTiago Martins Peres

    5411418




    5411418








    • 3





      A lot of people forget that the Manifesto lists eight important values, not four. The Manifesto makes a relative value judgement that the values on the left are more important than the values on the right, but it does not say that the values on the right are not important. The Manifesto explicitly says: "there is value in the items on the right". +1 for pointing that out!

      – Jörg W Mittag
      4 hours ago














    • 3





      A lot of people forget that the Manifesto lists eight important values, not four. The Manifesto makes a relative value judgement that the values on the left are more important than the values on the right, but it does not say that the values on the right are not important. The Manifesto explicitly says: "there is value in the items on the right". +1 for pointing that out!

      – Jörg W Mittag
      4 hours ago








    3




    3





    A lot of people forget that the Manifesto lists eight important values, not four. The Manifesto makes a relative value judgement that the values on the left are more important than the values on the right, but it does not say that the values on the right are not important. The Manifesto explicitly says: "there is value in the items on the right". +1 for pointing that out!

    – Jörg W Mittag
    4 hours ago





    A lot of people forget that the Manifesto lists eight important values, not four. The Manifesto makes a relative value judgement that the values on the left are more important than the values on the right, but it does not say that the values on the right are not important. The Manifesto explicitly says: "there is value in the items on the right". +1 for pointing that out!

    – Jörg W Mittag
    4 hours ago











    4














    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.



    Adding this section to respond to the comment:



    Agile and Scrum can be confusing to adopt because there are a lot of good practices that people have come up with that have been lumped into Agile and Scrum, while at the same time, many of the core practices and principles get left out.



    Agile: Agile is just values statements and principles. You can find them at https://agilemanifesto.org/. You can't really practice Agile - rather, your practices can be more or less Agile (as an adjective) depending on how well aligned they are with these values and principles.



    Scrum: You can follow Scrum practices. Scrum is a lightweight framework, meaning it gives a number of events, artifacts, roles, and practices, but there's a lot of space to fill in how you do the work and what that work looks like. You can find the latest version of the Scrum Guides at https://www.scrumguides.org/scrum-guide.html. It is probably worth noting that if many teams pick and choose what to follow out of Scrum. While that isn't inherently wrong, it is designed to work as a whole and many benefits are lost when you start dropping practices.



    XP: You didn't mention this, but a lot of practices common in Scrum that aren't specifically listed in the Scrum Guide (like User Stories) are actually from XP. XP is a lot more prescriptive on how to do the work. There's a pretty big change curve with adopting XP and I don't see many teams do it, but when Scrum started, they were often assuming that XP was going to fill some of the how-to space in their framework, so it's always worth looking at. http://www.extremeprogramming.org/ is a good place to start, if a bit clunky.






    share|improve this answer


























    • Seconding this. The ISO rules simply say you need a well defined process. If your company decides that process includes SRS and BRS then your company needs to define how, if at all, the agile processes generate those documents. If your company decides that user stories will be the SRS or BRS then simply write that down as your process and follow it to make ISO happy.

      – Pace
      8 hours ago











    • you mean that is no Agile-Specific ISO, How do I ensure that I follow Agile? many per attempts tended to be waterfall, sorry it seem to be another question.

      – Mjd Kassem
      8 hours ago











    • I added a bit more to respond to the "following Agile" question. I hope that helps.

      – Daniel
      7 hours ago
















    4














    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.



    Adding this section to respond to the comment:



    Agile and Scrum can be confusing to adopt because there are a lot of good practices that people have come up with that have been lumped into Agile and Scrum, while at the same time, many of the core practices and principles get left out.



    Agile: Agile is just values statements and principles. You can find them at https://agilemanifesto.org/. You can't really practice Agile - rather, your practices can be more or less Agile (as an adjective) depending on how well aligned they are with these values and principles.



    Scrum: You can follow Scrum practices. Scrum is a lightweight framework, meaning it gives a number of events, artifacts, roles, and practices, but there's a lot of space to fill in how you do the work and what that work looks like. You can find the latest version of the Scrum Guides at https://www.scrumguides.org/scrum-guide.html. It is probably worth noting that if many teams pick and choose what to follow out of Scrum. While that isn't inherently wrong, it is designed to work as a whole and many benefits are lost when you start dropping practices.



    XP: You didn't mention this, but a lot of practices common in Scrum that aren't specifically listed in the Scrum Guide (like User Stories) are actually from XP. XP is a lot more prescriptive on how to do the work. There's a pretty big change curve with adopting XP and I don't see many teams do it, but when Scrum started, they were often assuming that XP was going to fill some of the how-to space in their framework, so it's always worth looking at. http://www.extremeprogramming.org/ is a good place to start, if a bit clunky.






    share|improve this answer


























    • Seconding this. The ISO rules simply say you need a well defined process. If your company decides that process includes SRS and BRS then your company needs to define how, if at all, the agile processes generate those documents. If your company decides that user stories will be the SRS or BRS then simply write that down as your process and follow it to make ISO happy.

      – Pace
      8 hours ago











    • you mean that is no Agile-Specific ISO, How do I ensure that I follow Agile? many per attempts tended to be waterfall, sorry it seem to be another question.

      – Mjd Kassem
      8 hours ago











    • I added a bit more to respond to the "following Agile" question. I hope that helps.

      – Daniel
      7 hours ago














    4












    4








    4







    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.



    Adding this section to respond to the comment:



    Agile and Scrum can be confusing to adopt because there are a lot of good practices that people have come up with that have been lumped into Agile and Scrum, while at the same time, many of the core practices and principles get left out.



    Agile: Agile is just values statements and principles. You can find them at https://agilemanifesto.org/. You can't really practice Agile - rather, your practices can be more or less Agile (as an adjective) depending on how well aligned they are with these values and principles.



    Scrum: You can follow Scrum practices. Scrum is a lightweight framework, meaning it gives a number of events, artifacts, roles, and practices, but there's a lot of space to fill in how you do the work and what that work looks like. You can find the latest version of the Scrum Guides at https://www.scrumguides.org/scrum-guide.html. It is probably worth noting that if many teams pick and choose what to follow out of Scrum. While that isn't inherently wrong, it is designed to work as a whole and many benefits are lost when you start dropping practices.



    XP: You didn't mention this, but a lot of practices common in Scrum that aren't specifically listed in the Scrum Guide (like User Stories) are actually from XP. XP is a lot more prescriptive on how to do the work. There's a pretty big change curve with adopting XP and I don't see many teams do it, but when Scrum started, they were often assuming that XP was going to fill some of the how-to space in their framework, so it's always worth looking at. http://www.extremeprogramming.org/ is a good place to start, if a bit clunky.






    share|improve this answer















    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.



    Adding this section to respond to the comment:



    Agile and Scrum can be confusing to adopt because there are a lot of good practices that people have come up with that have been lumped into Agile and Scrum, while at the same time, many of the core practices and principles get left out.



    Agile: Agile is just values statements and principles. You can find them at https://agilemanifesto.org/. You can't really practice Agile - rather, your practices can be more or less Agile (as an adjective) depending on how well aligned they are with these values and principles.



    Scrum: You can follow Scrum practices. Scrum is a lightweight framework, meaning it gives a number of events, artifacts, roles, and practices, but there's a lot of space to fill in how you do the work and what that work looks like. You can find the latest version of the Scrum Guides at https://www.scrumguides.org/scrum-guide.html. It is probably worth noting that if many teams pick and choose what to follow out of Scrum. While that isn't inherently wrong, it is designed to work as a whole and many benefits are lost when you start dropping practices.



    XP: You didn't mention this, but a lot of practices common in Scrum that aren't specifically listed in the Scrum Guide (like User Stories) are actually from XP. XP is a lot more prescriptive on how to do the work. There's a pretty big change curve with adopting XP and I don't see many teams do it, but when Scrum started, they were often assuming that XP was going to fill some of the how-to space in their framework, so it's always worth looking at. http://www.extremeprogramming.org/ is a good place to start, if a bit clunky.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 7 hours ago

























    answered 9 hours ago









    DanielDaniel

    8,64921125




    8,64921125













    • Seconding this. The ISO rules simply say you need a well defined process. If your company decides that process includes SRS and BRS then your company needs to define how, if at all, the agile processes generate those documents. If your company decides that user stories will be the SRS or BRS then simply write that down as your process and follow it to make ISO happy.

      – Pace
      8 hours ago











    • you mean that is no Agile-Specific ISO, How do I ensure that I follow Agile? many per attempts tended to be waterfall, sorry it seem to be another question.

      – Mjd Kassem
      8 hours ago











    • I added a bit more to respond to the "following Agile" question. I hope that helps.

      – Daniel
      7 hours ago



















    • Seconding this. The ISO rules simply say you need a well defined process. If your company decides that process includes SRS and BRS then your company needs to define how, if at all, the agile processes generate those documents. If your company decides that user stories will be the SRS or BRS then simply write that down as your process and follow it to make ISO happy.

      – Pace
      8 hours ago











    • you mean that is no Agile-Specific ISO, How do I ensure that I follow Agile? many per attempts tended to be waterfall, sorry it seem to be another question.

      – Mjd Kassem
      8 hours ago











    • I added a bit more to respond to the "following Agile" question. I hope that helps.

      – Daniel
      7 hours ago

















    Seconding this. The ISO rules simply say you need a well defined process. If your company decides that process includes SRS and BRS then your company needs to define how, if at all, the agile processes generate those documents. If your company decides that user stories will be the SRS or BRS then simply write that down as your process and follow it to make ISO happy.

    – Pace
    8 hours ago





    Seconding this. The ISO rules simply say you need a well defined process. If your company decides that process includes SRS and BRS then your company needs to define how, if at all, the agile processes generate those documents. If your company decides that user stories will be the SRS or BRS then simply write that down as your process and follow it to make ISO happy.

    – Pace
    8 hours ago













    you mean that is no Agile-Specific ISO, How do I ensure that I follow Agile? many per attempts tended to be waterfall, sorry it seem to be another question.

    – Mjd Kassem
    8 hours ago





    you mean that is no Agile-Specific ISO, How do I ensure that I follow Agile? many per attempts tended to be waterfall, sorry it seem to be another question.

    – Mjd Kassem
    8 hours ago













    I added a bit more to respond to the "following Agile" question. I hope that helps.

    – Daniel
    7 hours ago





    I added a bit more to respond to the "following Agile" question. I hope that helps.

    – Daniel
    7 hours ago











    0














    Customer-side BA here, currently in the middle of a large-scale enterprise data warehousing and infrastructure modernization initiative. The project teams use Jira instead of TFS, and though the concepts are the same, our use of the platform is mainly as an tracking and reporting tool interface with the core Agile team. The focus of our user stories are mainly to discuss and track testing, enhancement requirements, defect reporting - all of the type of feedback that comes "after the fact" of each sprint's work-product, so to speak, and well after the initial requirements have been published.



    Key commentary on the BRS/SRS specification - these should be solicited from end-users in the planning/prototyping phase in order to prioritize architecture development and to develop the overall project plan; user stories, on the other hand, tend to be more focused on responding to feedback over particular channels, services, domains, or templates that arise after consumers have conducted feasibility and gaps analysis against the prototyped release.



    In short - while the exact purpose of each document will vary across different organizations and projects, the requirements documentation and user stores are ultimately apples-to-oranges, however all three could feasibly be combined in the same basket of fruit. Emphasis on the role of each should be tailored to the interests of the group(s) driving the initiative.



    End-users will set their requirements ahead of time and independently of the work being done in each sprint; they will likewise continuously adjust their plan in alignment with BA/DevOps feedback along the way - this communication gets relayed through the user stories during development as a tracking bulletin of sorts. The three are complimentary, but oftentimes they'll serve to document the interests and needs or distinctly different shareholder groups.






    share|improve this answer








    New contributor




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

























      0














      Customer-side BA here, currently in the middle of a large-scale enterprise data warehousing and infrastructure modernization initiative. The project teams use Jira instead of TFS, and though the concepts are the same, our use of the platform is mainly as an tracking and reporting tool interface with the core Agile team. The focus of our user stories are mainly to discuss and track testing, enhancement requirements, defect reporting - all of the type of feedback that comes "after the fact" of each sprint's work-product, so to speak, and well after the initial requirements have been published.



      Key commentary on the BRS/SRS specification - these should be solicited from end-users in the planning/prototyping phase in order to prioritize architecture development and to develop the overall project plan; user stories, on the other hand, tend to be more focused on responding to feedback over particular channels, services, domains, or templates that arise after consumers have conducted feasibility and gaps analysis against the prototyped release.



      In short - while the exact purpose of each document will vary across different organizations and projects, the requirements documentation and user stores are ultimately apples-to-oranges, however all three could feasibly be combined in the same basket of fruit. Emphasis on the role of each should be tailored to the interests of the group(s) driving the initiative.



      End-users will set their requirements ahead of time and independently of the work being done in each sprint; they will likewise continuously adjust their plan in alignment with BA/DevOps feedback along the way - this communication gets relayed through the user stories during development as a tracking bulletin of sorts. The three are complimentary, but oftentimes they'll serve to document the interests and needs or distinctly different shareholder groups.






      share|improve this answer








      New contributor




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























        0












        0








        0







        Customer-side BA here, currently in the middle of a large-scale enterprise data warehousing and infrastructure modernization initiative. The project teams use Jira instead of TFS, and though the concepts are the same, our use of the platform is mainly as an tracking and reporting tool interface with the core Agile team. The focus of our user stories are mainly to discuss and track testing, enhancement requirements, defect reporting - all of the type of feedback that comes "after the fact" of each sprint's work-product, so to speak, and well after the initial requirements have been published.



        Key commentary on the BRS/SRS specification - these should be solicited from end-users in the planning/prototyping phase in order to prioritize architecture development and to develop the overall project plan; user stories, on the other hand, tend to be more focused on responding to feedback over particular channels, services, domains, or templates that arise after consumers have conducted feasibility and gaps analysis against the prototyped release.



        In short - while the exact purpose of each document will vary across different organizations and projects, the requirements documentation and user stores are ultimately apples-to-oranges, however all three could feasibly be combined in the same basket of fruit. Emphasis on the role of each should be tailored to the interests of the group(s) driving the initiative.



        End-users will set their requirements ahead of time and independently of the work being done in each sprint; they will likewise continuously adjust their plan in alignment with BA/DevOps feedback along the way - this communication gets relayed through the user stories during development as a tracking bulletin of sorts. The three are complimentary, but oftentimes they'll serve to document the interests and needs or distinctly different shareholder groups.






        share|improve this answer








        New contributor




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










        Customer-side BA here, currently in the middle of a large-scale enterprise data warehousing and infrastructure modernization initiative. The project teams use Jira instead of TFS, and though the concepts are the same, our use of the platform is mainly as an tracking and reporting tool interface with the core Agile team. The focus of our user stories are mainly to discuss and track testing, enhancement requirements, defect reporting - all of the type of feedback that comes "after the fact" of each sprint's work-product, so to speak, and well after the initial requirements have been published.



        Key commentary on the BRS/SRS specification - these should be solicited from end-users in the planning/prototyping phase in order to prioritize architecture development and to develop the overall project plan; user stories, on the other hand, tend to be more focused on responding to feedback over particular channels, services, domains, or templates that arise after consumers have conducted feasibility and gaps analysis against the prototyped release.



        In short - while the exact purpose of each document will vary across different organizations and projects, the requirements documentation and user stores are ultimately apples-to-oranges, however all three could feasibly be combined in the same basket of fruit. Emphasis on the role of each should be tailored to the interests of the group(s) driving the initiative.



        End-users will set their requirements ahead of time and independently of the work being done in each sprint; they will likewise continuously adjust their plan in alignment with BA/DevOps feedback along the way - this communication gets relayed through the user stories during development as a tracking bulletin of sorts. The three are complimentary, but oftentimes they'll serve to document the interests and needs or distinctly different shareholder groups.







        share|improve this answer








        New contributor




        JJ Ward 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 answer



        share|improve this answer






        New contributor




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









        answered 54 mins ago









        JJ WardJJ Ward

        1




        1




        New contributor




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





        New contributor





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






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






















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










            draft saved

            draft discarded


















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













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












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
















            Thanks for contributing an answer to Project Management Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25875%2fwhere-does-documentation-like-business-and-software-requirement-spec-docs-fit-in%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            How to label and detect the document text images

            Vallis Paradisi

            Tabula Rosettana