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

How can guns be countered by melee combat without raw-ability or exceptional explanations?

Is layered encryption more secure than long passwords?

Why do objects rebound after hitting the ground?

Is there any good browser plugin or tool to quickly identify any security issues of a web site?

Promise.all returning empty objects

How do I fight with Heavy Armor as a Wizard with Tenser's Transformation?

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"?

Is Screenshot Time-tracking Common?

Sticky Strike or Sticky Delta

Even as admin, I cannot edit DefaultFonts.plist for Notes.app. What am I doing wrong?

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

Smooth projection of a surf plot - tikz/gnuplot

Renting a 2CV in France

Is it really OK to use "because of"?

How can I deduce the power of a capacitor from its datasheet?

Other than edits for international editions, did Harry Potter and the Philosopher's Stone receive errata?

How do I add a strong "onion flavor" to the biryani (in restaurant style)?

Lubuntu 18.10 File Manager: How to view directory tree structure?

Why do neural networks need so many examples to perform?

Is it recommended to be 100% delegated for a baker?

How do I avoid the "chosen hero" feeling?

Given a total recursive function, can you always compute its fixed-point?

What's the reason that we have a different number of days each month?

How can I prevent an oracle who can see into the past from knowing everything that has happened?



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


What percentage of a project manager's time should be spent working in the project management software and documentation?What artifacts does Scrum require for application design and systems documentation?What does MOS and RA stand for in IT project?Comprehensive single requirement docs vs. multiple atomic onesHow do the following QA, Business Analyst, Developer and lead or architect fit in scrumAre presentations considered “documentation” when applying Agile and Scrum to BI?Organizing testing in a Scrum(ish) development projectWhere to start in agile-based documentations and what are the best practices to start with?Where is the place for project managers in agileWhat Does “Commitment” Look Like with Agile Projects?













1















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.
















  • 1





    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
    55 mins 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
    26 mins ago


















1















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.
















  • 1





    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
    55 mins 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
    26 mins ago
















1












1








1








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 15 mins 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 2 hours ago









Mjd KassemMjd Kassem

61




61




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.








  • 1





    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
    55 mins 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
    26 mins ago
















  • 1





    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
    55 mins 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
    26 mins ago










1




1





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
55 mins 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
55 mins 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
26 mins 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
26 mins ago












2 Answers
2






active

oldest

votes


















3














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































    2














    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
























    • 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
      1 hour 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
      14 mins ago











    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

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3














    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














      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












        3








        3







        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 1 hour ago









        Tiago Martins PeresTiago Martins Peres

        5011418




        5011418























            2














            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
























            • 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
              1 hour 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
              14 mins ago
















            2














            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
























            • 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
              1 hour 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
              14 mins ago














            2












            2








            2







            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













            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












            share|improve this answer



            share|improve this answer










            answered 1 hour ago









            DanielDaniel

            8,61921125




            8,61921125













            • 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
              1 hour 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
              14 mins 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
              1 hour 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
              14 mins 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
            1 hour 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
            1 hour 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
            14 mins 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
            14 mins ago










            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

            Szabolcs (Ungheria) Altri progetti | Menu di navigazione48°10′14.56″N 21°29′33.14″E /...

            Discografia di Klaus Schulze Indice Album in studio | Album dal vivo | Singoli | Antologie | Colonne...

            How to make inet_server_addr() return localhost in spite of ::1/128RETURN NEXT in Postgres FunctionConnect to...