Loading ...
Sorry, an error occurred while loading the content.

[scrumdevelopment] SCRUM Requirements Documentation and tracking

Expand Messages
  • BELLAMKONDA Ravi
    I am a new bee to SCRUM. I am helping as a business analyst for a team developing a large system using Scrum. Almost requirements are received from Business
    Message 1 of 8 , May 1, 2007
    • 0 Attachment
      I am a new bee to SCRUM. I am helping as a business analyst for a team developing a large system using Scrum. Almost requirements are received from Business same time for Dev, QA and BA. They are captured as Clear quest stories and tracked. But some times dev struggle with lack of documentation. It is difficult to document because of two week sprint deliveries. Development mostly done through collaboration, but users would like the BAs to have some documentation as well as developers and some new bees joining the project may need some documentation as well.

      I am Coming from RUP world - how do I document requirements in SCRUM.? I have heard of user stories... Is there a std way to capture and track these?Are there any guidelines.? how these are captured and tracked.? Is there a traceability anywhere of these tasks to the features/vision etc.? Are there any tools available on SCRUM .?

      what is equivalent of RUP usecases, features - activity diagrams etc -> what documents typically development team use in SCRUM? and user community in future.?What is the importance of UML modeling in Scrum world.? Does it encourage No modeling at all.?

      Any help is appreciated..

      Thanks,

      Ravi Bellamkonda,PMP

      IBM Certified Specialist for RUP

      rbellamkonda@...

      Confidentiality Statement:

      This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by return email.
      -----------------------------
    • bc purushotham
      Hi Ravi, Its really good question with respect to SCRUM. Currently we are using very simple process to document the requirements, not spending to much time in
      Message 2 of 8 , May 1, 2007
      • 0 Attachment
        Hi Ravi,

        Its really good question with respect to SCRUM.

        Currently we are using very simple process to document
        the requirements, not spending to much time in
        preparing use case diagrams/usage scenarios.

        different kind of scrum tools avialable in the market.

        VSTS 2005 with scrum template is good choice for
        creating and tracking the work items.
        ScrumWorks is also good.

        Cheers,
        Purshi
        Prince2, CSM



        --- BELLAMKONDA Ravi <RBellamkonda@...>
        wrote:

        > I am a new bee to SCRUM. I am helping as a business
        > analyst for a team developing a large system using
        > Scrum. Almost requirements are received from
        > Business same time for Dev, QA and BA. They are
        > captured as Clear quest stories and tracked. But
        > some times dev struggle with lack of documentation.
        > It is difficult to document because of two week
        > sprint deliveries. Development mostly done through
        > collaboration, but users would like the BAs to have
        > some documentation as well as developers and some
        > new bees joining the project may need some
        > documentation as well.
        >
        > I am Coming from RUP world - how do I document
        > requirements in SCRUM.? I have heard of user
        > stories... Is there a std way to capture and track
        > these?Are there any guidelines.? how these are
        > captured and tracked.? Is there a traceability
        > anywhere of these tasks to the features/vision etc.?
        > Are there any tools available on SCRUM .?
        >
        > what is equivalent of RUP usecases, features -
        > activity diagrams etc -> what documents typically
        > development team use in SCRUM? and user community in
        > future.?What is the importance of UML modeling in
        > Scrum world.? Does it encourage No modeling at all.?
        >
        > Any help is appreciated..
        >
        > Thanks,
        >
        > Ravi Bellamkonda,PMP
        >
        > IBM Certified Specialist for RUP
        >
        > rbellamkonda@...
        >
        > Confidentiality Statement:
        >
        > This message is intended only for the individual or
        > entity to which it is addressed. It may contain
        > privileged, confidential information which is exempt
        > from disclosure under applicable laws. If you are
        > not the intended recipient, please note that you are
        > strictly prohibited from disseminating or
        > distributing this information (other than to the
        > intended recipient) or copying this information. If
        > you have received this communication in error,
        > please notify us immediately by return email.
        > -----------------------------
        >


        __________________________________________________
        Do You Yahoo!?
        Tired of spam? Yahoo! Mail has the best spam protection around
        http://mail.yahoo.com
      • Nicholas Cancelliere
        You should read User Stories Applied, by Mike Cohn. It s a good start. There is also a Audio CD called Agile Requirements and User Stories. Scott Ambler
        Message 3 of 8 , May 2, 2007
        • 0 Attachment
           
          You should read User Stories Applied, by Mike Cohn.  It's a good start.  There is also a Audio CD called Agile Requirements and User Stories.  Scott Ambler wrote some on the subject at his web site as well.
           
          I actually work as a BA / Scrummaster at my current job (it's a small development company, so we have to all wear different hats).  I am unfamiliar with Clear Quest stories ... but what you want to do is make sure you're providing the right level of detail at the right time.  Also only generate artifacts that will actually be used by the team and are beneficial... not simply because the process prescribes it.  Ask the team what they need in way of documentation.  If you don't nkow how much details the team needs at a given point in a project, just ask them - they'll be happy to tell you what they need to make an estimate, for example.
           
          I'd avoid, if I could, anything that is done simply because it's perscribed - but offers little value for the effort to produce such documentation.  Also anything that is duplicate work, avoid that too.  (I get the feeling a lot of documentation is to CYA in projects, but it should be for communicating ... and paper documents are one of the worst forms of communication.  Coversational mediums - face to face, telephone, IM - are suprior to documents.  Remember conversation is two-way communication!
           
          Usually it is more useful to update the acceptance tests then it is "documentation" because at the end of the day this is what defines the requirements of a feature as it tells us what "done" means.  So in this sense if you're updating the acceptance tests don't also updating a Clear Quest case (dupliate work).  I don't know what it's like where you work - but I would maybe try to get away from the RUP documents and try to go more along with User Stories.
           
          Nicholas

           
          On 5/1/07, BELLAMKONDA Ravi <RBellamkonda@...> wrote:

          I am a new bee to SCRUM. I am helping as a business analyst for a team developing a large system using Scrum. Almost requirements are received from Business same time for Dev, QA and BA. They are captured as Clear quest stories and tracked. But some times dev struggle with lack of documentation. It is difficult to document because of two week sprint deliveries. Development mostly done through collaboration, but users would like the BAs to have some documentation as well as developers and some new bees joining the project may need some documentation as well.

          I am Coming from RUP world - how do I document requirements in SCRUM.? I have heard of user stories... Is there a std way to capture and track these?Are there any guidelines.? how these are captured and tracked.? Is there a traceability anywhere of these tasks to the features/vision etc.? Are there any tools available on SCRUM .?

          what is equivalent of RUP usecases, features - activity diagrams etc -> what documents typically development team use in SCRUM? and user community in future.?What is the importance of UML modeling in Scrum world.? Does it encourage No modeling at all.?

          Any help is appreciated..

          Thanks,

          Ravi Bellamkonda,PMP

          IBM Certified Specialist for RUP

          rbellamkonda@...

          Confidentiality Statement:

          This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by return email.
          -----------------------------





          --
          Nicholas Cancelliere, Austin TX
          "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
        • Oldfield, Paul (ASPIRE)
          (responding to Ravi) ... SCRUM does not specify an Engineering process, but it will help uncover problems in your existing engineering process. Reading between
          Message 4 of 8 , May 3, 2007
          • 0 Attachment
            (responding to Ravi)

            > I am Coming from RUP world - how do I document requirements in
            > SCRUM.? I have heard of user stories... Is there a std way to capture
            > and track these?Are there any guidelines.? how these are captured
            > and tracked.? Is there a traceability anywhere of these tasks to the
            > features/vision etc.? Are there any tools available on SCRUM .?

            SCRUM does not specify an Engineering process, but it will help
            uncover problems in your existing engineering process.

            Reading between the lines, your developers are feeling insecure
            without having more documentation. They might be trying to do
            the project work in lumps that are too big, so they cannot hold all
            the information they need in their heads. This means they need to
            queue the work. Ideally, we would like the work queue to exist
            as a prioritised list of user stories at a high level, and as a set of
            tasks to complete one (or two?) current stories.

            Test-driven development (TDD) advocates writing one test at a time,
            and then writing the code to change that test from one that fails
            to one that passes. This approach helps ensure that your
            developers are not trying to do the work in chunks that are too
            big.

            Another potential cause of wanting more documentation is where
            there is hand-off between roles. If your team is not cross-functional,
            I recommend more collaborative ways of working to cut down on
            the need for documentation, and also work toward cross-functional
            teams. Again, collaborative working helps folk understand what
            is involved in other people's jobs.

            > What is the importance of UML modeling in Scrum world.? Does
            > it encourage No modeling at all.?

            You might find the yahoo group on agilemodeling can help you on
            questions in this area.

            Paul Oldfield
          • mnbluesguy
            We use to have a number of similiar problems. We are doing the following things: 1. We literally use sticky 3x5 cards to document the stories. The stories
            Message 5 of 8 , May 3, 2007
            • 0 Attachment
              We use to have a number of similiar problems. We are doing the
              following things:

              1. We literally use 'sticky' 3x5 cards to document the stories. The
              stories were developed from story gathering meetings & prioritization
              meetings.

              2. We capture details about the stories for a Sprint during our
              Sprint Planning Meetings. The information is capture on white boards
              (which we digitally capture and save in Sharepoint). For each product
              backlog item to be worked on we come up with a set of sprint backlog
              items for each PBI.

              3. The BA/QA & developers are in a team room. The team room has lots
              of whiteboards and they document what they learn on the whiteboards as
              they go.

              4. The team works on one story at a time. This helps keep everyone
              very focused on what they are doing.

              5. The user works closely with the BA/QA to develop Fit tests for the
              UAT on each story.

              It has taken about 18-24 months (the last 12 months being the most
              intense) to reach this point. It is working pretty well. Everyone
              has learned to accept that we have uncertainity with each story and it
              is important to collaborate and ask lots of questions instead of
              making assumptions.

              Good luck,
              David Tannen
            • Peter Jobbagy
              David, How do you handle system documentation that reflects current state and changes? Thanks, Peter Jobbagy ________________________________ From:
              Message 6 of 8 , May 3, 2007
              • 0 Attachment

                David,

                 

                How do you handle system documentation that reflects current state and changes?

                 

                Thanks,

                 

                Peter Jobbagy

                 

                 


                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of mnbluesguy
                Sent: Thursday, May 03, 2007 11:35 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Re: SCRUM Requirements Documentation and tracking

                 

                We use to have a number of similiar problems. We are doing the
                following things:

                1. We literally use 'sticky' 3x5 cards to document the stories. The
                stories were developed from story gathering meetings & prioritization
                meetings.

                2. We capture details about the stories for a Sprint during our
                Sprint Planning Meetings. The information is capture on white boards
                (which we digitally capture and save in Sharepoint). For each product
                backlog item to be worked on we come up with a set of sprint backlog
                items for each PBI.

                3. The BA/QA & developers are in a team room. The team room has lots
                of whiteboards and they document what they learn on the whiteboards as
                they go.

                4. The team works on one story at a time. This helps keep everyone
                very focused on what they are doing.

                5. The user works closely with the BA/QA to develop Fit tests for the
                UAT on each story.

                It has taken about 18-24 months (the last 12 months being the most
                intense) to reach this point. It is working pretty well. Everyone
                has learned to accept that we have uncertainity with each story and it
                is important to collaborate and ask lots of questions instead of
                making assumptions.

                Good luck,
                David Tannen

              • Marchi, Michael
                Ravi, Scrum does not say that you do no documentation. Scrum says you should have no more documentation than you need to have. It goes a little further to
                Message 7 of 8 , Aug 1, 2010
                • 0 Attachment

                  Ravi,

                   

                  Scrum does not say that you do no documentation.  Scrum says you should have no more documentation than you need to have.  It goes a little further to say that Scrum (itself) requires no documentatation – which I think is where most of the confusion originates.

                   

                  On  a large-scale project, you will certainly need SOME documentation to capture key interaction and architectures that are shared among teams.  If your project is complex enough that such documentation is needed, then those documents should be part of the Sprint deliverables as well.  The trick is determining how much is enough.

                   

                  Keep in mind this principal behind the Agile Manifesto: “Simplicity--the art of maximizing the amount of work not done--is essential.”  That is to say, don’t fall into the trap of having to design your entire architecture, or complete volumes and volumes of design documentation prior to STARTING to work.  In a large-scale, multi-team project, I like the idea of having an “architecture team” that works just far enough ahead of the development teams to ensure that the next bits of work are defined enough for the teams to move confidently forward. 

                   

                  Many of the tools you are used to using still have a role in an agile project.  Agility is in how you apply those tools.

                   

                  Regards,

                  Michael Marchi

                   

                  Siemens Industry, Inc.

                  Building Technologies

                  michael.marchi@...

                  SW Engineer IV, CSM, CSPO, CSP, Agile Coach and Trainer

                   

                   


                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of BELLAMKONDA Ravi
                  Sent: Tuesday, May 01, 2007 3:37 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] SCRUM Requirements Documentation and tracking

                   

                  I am a new bee to SCRUM. I am helping as a business analyst for a team developing a large system using Scrum. Almost requirements are received from Business same time for Dev, QA and BA. They are captured as Clear quest stories and tracked. But some times dev struggle with lack of documentation. It is difficult to document because of two week sprint deliveries. Development mostly done through collaboration, but users would like the BAs to have some documentation as well as developers and some new bees joining the project may need some documentation as well.

                  I am Coming from RUP world - how do I document requirements in SCRUM.? I have heard of user stories... Is there a std way to capture and track these?Are there any guidelines.?  how these are captured and tracked.? Is there a traceability anywhere of these tasks to the features/vision etc.? Are there any tools available on SCRUM .?

                  what is equivalent of RUP usecases, features - activity diagrams etc -> what documents typically development team use in SCRUM? and user community in future.?What is the importance of UML modeling in Scrum world.? Does it encourage No modeling at all.?

                  Any help is appreciated..

                  Thanks,

                  Ravi Bellamkonda,PMP

                  IBM Certified Specialist for RUP

                  rbellamkonda@...

                   

                  Confidentiality Statement:

                   

                  This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by return email.

                  -----------------------------

                   

                • Dan Rawsthorne
                  Scrum does not require documentation. But you project and/or product might. Dan Rawsthorne, PhD, CST Senior Trainer/Coach, CollabNet drawsthorne@collab.net,
                  Message 8 of 8 , Aug 1, 2010
                  • 0 Attachment
                    Scrum does not require documentation. But you project and/or product might.

                    Dan Rawsthorne, PhD, CST
                    Senior Trainer/Coach, CollabNet
                    drawsthorne@..., 425-269-8628



                    Marchi, Michael wrote:
                    >
                    > Ravi,
                    >
                    > Scrum does not say that you do no documentation. Scrum says you should
                    > have no more documentation than you need to have. It goes a little
                    > further to say that Scrum (itself) requires no documentatation – which
                    > I think is where most of the confusion originates.
                    >
                    > On a large-scale project, you will certainly need SOME documentation
                    > to capture key interaction and architectures that are shared among
                    > teams. If your project is complex enough that such documentation is
                    > needed, then those documents should be part of the Sprint deliverables
                    > as well. The trick is determining how much is enough.
                    >
                    > Keep in mind this principal behind the Agile Manifesto:
                    > “Simplicity--the art of maximizing the amount of work not done--is
                    > essential.” That is to say, don’t fall into the trap of having to
                    > design your entire architecture, or complete volumes and volumes of
                    > design documentation prior to STARTING to work. In a large-scale,
                    > multi-team project, I like the idea of having an “architecture team”
                    > that works just far enough ahead of the development teams to ensure
                    > that the next bits of work are defined enough for the teams to move
                    > confidently forward.
                    >
                    > Many of the tools you are used to using still have a role in an agile
                    > project. Agility is in how you apply those tools.
                    >
                    > Regards,
                    >
                    > Michael Marchi
                    >
                    > Siemens Industry, Inc.
                    >
                    > Building Technologies
                    >
                    > michael.marchi@... <mailto:michael.marchi@...>
                    >
                    > SW Engineer IV, CSM, CSPO, CSP, Agile Coach and Trainer
                    >
                    > ------------------------------------------------------------------------
                    >
                    > *From:* scrumdevelopment@yahoogroups.com
                    > [mailto:scrumdevelopment@yahoogroups.com] *On Behalf Of *BELLAMKONDA Ravi
                    > *Sent:* Tuesday, May 01, 2007 3:37 PM
                    > *To:* scrumdevelopment@yahoogroups.com
                    > *Subject:* [scrumdevelopment] SCRUM Requirements Documentation and
                    > tracking
                    >
                    > I am a new bee to SCRUM. I am helping as a business analyst for a team
                    > developing a large system using Scrum. Almost requirements are
                    > received from Business same time for Dev, QA and BA. They are captured
                    > as Clear quest stories and tracked. But some times dev struggle with
                    > lack of documentation. It is difficult to document because of two week
                    > sprint deliveries. Development mostly done through collaboration, but
                    > users would like the BAs to have some documentation as well as
                    > developers and some new bees joining the project may need some
                    > documentation as well.
                    >
                    > I am Coming from RUP world - how do I document requirements in SCRUM.?
                    > I have heard of user stories... Is there a std way to capture and
                    > track these?Are there any guidelines.? how these are captured and
                    > tracked.? Is there a traceability anywhere of these tasks to the
                    > features/vision etc.? Are there any tools available on SCRUM .?
                    >
                    > what is equivalent of RUP usecases, features - activity diagrams etc
                    > -> what documents typically development team use in SCRUM? and user
                    > community in future.?What is the importance of UML modeling in Scrum
                    > world.? Does it encourage No modeling at all.?
                    >
                    > Any help is appreciated..
                    >
                    > Thanks,
                    >
                    > Ravi Bellamkonda,PMP
                    >
                    > IBM Certified Specialist for RUP
                    >
                    > rbellamkonda@... <mailto:rbellamkonda@...>
                    >
                    > Confidentiality Statement:
                    >
                    > This message is intended only for the individual or entity to which it
                    > is addressed. It may contain privileged, confidential information
                    > which is exempt from disclosure under applicable laws. If you are not
                    > the intended recipient, please note that you are strictly prohibited
                    > from disseminating or distributing this information (other than to the
                    > intended recipient) or copying this information. If you have received
                    > this communication in error, please notify us immediately by return email.
                    >
                    > -----------------------------
                    >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.