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

Tracebility

Expand Messages
  • Christiane Kuntz-Mayr
    Hi, we would like to exchange ideas how other companies ensure full implementation/tracebility of all selected requirements in Scrum projects: - Is a software
    Message 1 of 11 , May 30, 2007
      Hi,
      we would like to exchange ideas how other companies ensure full
      implementation/tracebility of all selected requirements in Scrum
      projects:
      - Is a software requirement/product backlog item regarded as
      implemented/done when the product owner accepts the implementation in a
      sprint review?
      - Is user documentation created incrementally and checked with the
      respective functionality in sprint reviews?
      - Are overall product acceptance tests regarded as necessary even in
      true scrum projects?
      Regards, Christiane
    • David H.
      ... Guten Abend ... It depends on how thorough you need to be. If you do not accept Backlog Items unless they have User Acceptance Tests tied to them, you
      Message 2 of 11 , May 30, 2007
        >
        > Hi,

        Guten Abend

        > we would like to exchange ideas how other companies ensure full
        > implementation/tracebility of all selected requirements in Scrum
        > projects:
        > - Is a software requirement/product backlog item regarded as
        > implemented/done when the product owner accepts the implementation in a
        > sprint review?

        It depends on how thorough you need to be. If you do not accept
        Backlog Items unless they have User Acceptance Tests tied to them, you
        might not wish to accept any of those Items as delivered unless all
        the User Acceptance Tests have run sucessfully and all other none
        functional bits which are part of the understanding of "Done" have
        been delivered.

        > - Is user documentation created incrementally and checked with the
        > respective functionality in sprint reviews?

        This, once more, depends on what your understanding of "DONE" is and
        what it has been agreed upon with the Product Owner. If each Item
        needs to show there is User documentation for that functionality, then
        yes. It needs to be produced. There are systems which support that
        very well, have a look at DITA

        > - Are overall product acceptance tests regarded as necessary even in
        > true scrum projects?

        In Theory, no. The incremental sign off on the project and the
        incremental integration should take care of all this. IN large
        organisations you might not get around something like a "Release
        Sprint"

        -d
        --
        Sent from gmail so do not trust this communication.
        Do not send me sensitive information here, ask for my none-gmail accounts.

        "Therefore the considerations of the intelligent always include both
        benefit and harm." - Sun Tzu
      • srinivas chillara
        Hello, ... Yes, basically, but if she has feedback which leads to changes etc, then that might be done later. ... Not necessarily. Sometimes this is done at
        Message 3 of 11 , May 30, 2007
          Hello,

          > - Is a software requirement/product backlog item
          > regarded as
          > implemented/done when the product owner accepts the
          > implementation in a
          > sprint review?

          Yes, basically, but if she has feedback which leads to
          changes etc, then that might be "done" later.

          > - Is user documentation created incrementally and
          > checked with the
          > respective functionality in sprint reviews?

          Not necessarily. Sometimes this is done at a draft
          level, and then suring the stabilization/release
          sprint the user documentation is polished.


          > - Are overall product acceptance tests regarded as
          > necessary even in
          > true scrum projects?

          I should think so. Particularly if the PO wants it.


          Hope this helps
          Cheenie




          Download prohibited? No problem! To chat from any browser without download, Click Here: http://in.messenger.yahoo.com/webmessengerpromo.php
        • bennyou.cpt1
          I also have a concern with reagards to Tracebility. With Scrum principles I tend to believe that requirements are gathered with a more of a just-in-time
          Message 4 of 11 , May 31, 2007
            I also have a concern with reagards to Tracebility.
            With Scrum principles I tend to believe that requirements are gathered
            with a more of a just-in-time approach using User Stories as
            placeholders for converstaions to take place at a later stage.

            My concern is as follows, I am working on a ongoing project, where
            there is a high turnover of members of the project (and perhaps I am
            answering/or exposing a bigger problem). There is a loss of IP and
            retionale for some of the decisions made. And thus there is a loss in
            tracibility.

            I feel that the Product Backlogs and Story Points are not enough to
            address these issues. Has anyone else experieced anything similar or
            have any suggestions to retain the intellectual property?
          • Banibrata Dutta
            Good to know that I am not the only one who has this particular concern. Without a robust Scrum tool which permits tracking, i.e. the leaner tools, this may be
            Message 5 of 11 , May 31, 2007
              Good to know that I am not the only one who has this particular concern.
              Without a robust Scrum tool which permits tracking, i.e. the leaner tools, this may be an issue.

              On 5/31/07, bennyou.cpt1 <bennyou.cpt@...> wrote:

              I also have a concern with reagards to Tracebility.
              With Scrum principles I tend to believe that requirements are gathered
              with a more of a just-in-time approach using User Stories as
              placeholders for converstaions to take place at a later stage.

              My concern is as follows, I am working on a ongoing project, where
              there is a high turnover of members of the project (and perhaps I am
              answering/or exposing a bigger problem). There is a loss of IP and
              retionale for some of the decisions made. And thus there is a loss in
              tracibility.

              I feel that the Product Backlogs and Story Points are not enough to
              address these issues. Has anyone else experieced anything similar or
              have any suggestions to retain the intellectual property?


            • David H.
              I think I do not understand the question, but this sounds to me like an issue of trust. Lack of trust to be precise. ... -- Sent from gmail so do not trust
              Message 6 of 11 , May 31, 2007
                I think I do not understand the question, but this sounds to me like
                an issue of trust. Lack of trust to be precise.

                >
                >
                >
                > Good to know that I am not the only one who has this particular concern.
                > Without a robust Scrum tool which permits tracking, i.e. the leaner tools,
                > this may be an issue.
                >
                > On 5/31/07, bennyou.cpt1 <bennyou.cpt@...> wrote:
                > >
                > >
                > >
                > >
                > >
                > >
                > > I also have a concern with reagards to Tracebility.
                > > With Scrum principles I tend to believe that requirements are gathered
                > > with a more of a just-in-time approach using User Stories as
                > > placeholders for converstaions to take place at a later stage.
                > >
                > > My concern is as follows, I am working on a ongoing project, where
                > > there is a high turnover of members of the project (and perhaps I am
                > > answering/or exposing a bigger problem). There is a loss of IP and
                > > retionale for some of the decisions made. And thus there is a loss in
                > > tracibility.
                > >
                > > I feel that the Product Backlogs and Story Points are not enough to
                > > address these issues. Has anyone else experieced anything similar or
                > > have any suggestions to retain the intellectual property?
                > >
                > >
                >
                >
                >
                >


                --
                Sent from gmail so do not trust this communication.
                Do not send me sensitive information here, ask for my none-gmail accounts.

                "Therefore the considerations of the intelligent always include both
                benefit and harm." - Sun Tzu
              • srinivas chillara
                There are only the (at the most four) artifacts generated by Scrum: 1. Product Backlog 2. Sprint Backlog 3. Burndown chart So if the product backlog is
                Message 7 of 11 , May 31, 2007
                  There are only the (at the most four) artifacts
                  generated by Scrum:
                  1. Product Backlog
                  2. Sprint Backlog
                  3. Burndown chart

                  So if the product backlog is maintained, how can
                  things/stories go missing, these items are tracked,
                  and so are the tasks that are being done, in a sprint
                  backlog?

                  Traceability is useful, if the product owner is
                  convinced then a filled-up tracability matrix could be
                  a criteria for "done".



                  > Without a robust Scrum tool which permits tracking,
                  > i.e. the leaner tools

                  I am not sure what you mean be a "robust" scrum tool.
                  It looks as though you want something that can support
                  a detailed tracking and many other artifacts, but also
                  accomodates Scrum (i.e the backlogs and burndown
                  charts are extra). If indeed this is the case, you are
                  on the slippery-slope towards documentation and audit
                  kingdom.



                  Did you know? You can CHAT without downloading messenger. Click here http://in.messenger.yahoo.com/webmessengerpromo.php
                • gddrennan
                  Having come from a previous environment (the US military) where we experienced frequent personnel turn-over I can relate to bennyou.cpt s situation. One of the
                  Message 8 of 11 , Jun 1 2:42 PM
                    Having come from a previous environment (the US military) where we
                    experienced frequent personnel turn-over I can relate to
                    bennyou.cpt's situation.

                    One of the ways that we used to maintain the "history" of why
                    decisions, designs or implementations were done a certain way was to
                    have each project person keep a journal with daily reflections
                    related to the project.

                    When person "A" left the project, his or her journal was turned over
                    to the person who replaced them. In this way we were able to pass
                    on historical information that might otherwise have been lost.

                    Were I to be involved in a similar situation today, instead of
                    journals, I think I would encourage the team members to setup a blog.

                    Having said all this, we don't have this problem at my current
                    employer as the teams I work with work on 3-4 week sprints
                    (depending on which project you look at) and so completing the
                    stories doesn't drag on long enough for us to encounter team member
                    turn-over.

                    Gregg

                    --- In scrumdevelopment@yahoogroups.com, srinivas chillara
                    <ceezone@...> wrote:
                    >
                    > There are only the (at the most four) artifacts
                    > generated by Scrum:
                    > 1. Product Backlog
                    > 2. Sprint Backlog
                    > 3. Burndown chart
                    >
                    > So if the product backlog is maintained, how can
                    > things/stories go missing, these items are tracked,
                    > and so are the tasks that are being done, in a sprint
                    > backlog?
                  • Michael Vizdos
                    Ahhh the slippery slope of traceability. One of the questions to ask yourself is, Who is requiring this? And another... What value is this to the team?
                    Message 9 of 11 , Jun 4 9:21 AM
                      Ahhh the slippery slope of "traceability."

                      One of the questions to ask yourself is, "Who is requiring this?"

                      And another... "What value is this to the team?"

                      If this is in fact valuable to the team (not some exec who will not show up to a stand-up meeting), then build it into each of your story estimates and make it very visible that this costs time for the team.  Yes, I know... sometimes the auditors have a field day with this topic.  But... maybe work with your auditors to see what is really needed.  The conversation may be eye opening :).

                      I discussed this topic in a blog entry (with a test of a podcast on it!) here:

                      http://www.implementingscrum.com/cartoons/cartoons_files/implementingscrum-20070409.html

                      - mike vizdos
                        www.implementingscrum.com
                        www.michaelvizdos.com



                      On 5/31/07, bennyou.cpt1 <bennyou.cpt@...> wrote:

                      I also have a concern with reagards to Tracebility.
                      With Scrum principles I tend to believe that requirements are gathered
                      with a more of a just-in-time approach using User Stories as
                      placeholders for converstaions to take place at a later stage.

                      My concern is as follows, I am working on a ongoing project, where
                      there is a high turnover of members of the project (and perhaps I am
                      answering/or exposing a bigger problem). There is a loss of IP and
                      retionale for some of the decisions made. And thus there is a loss in
                      tracibility.

                      I feel that the Product Backlogs and Story Points are not enough to
                      address these issues. Has anyone else experieced anything similar or
                      have any suggestions to retain the intellectual property?


                    • Nicholas Cancelliere
                      Why is the turnover on your project so high? It would seem like a risk or a challenge regardless whatever methodology you use. Why do you believe writing down
                      Message 10 of 11 , Jun 4 4:18 PM

                        Why is the turnover on your project so high?  It would seem like a risk or a challenge regardless whatever methodology you use.

                        Why do you believe writing down requirements will make anything better in terms of understanding?

                        Nicholas


                        On May 31, 2007, at 3:11 AM, bennyou.cpt1 wrote:

                        I also have a concern with reagards to Tracebility.
                        With Scrum principles I tend to believe that requirements are gathered
                        with a more of a just-in-time approach using User Stories as
                        placeholders for converstaions to take place at a later stage.

                        My concern is as follows, I am working on a ongoing project, where
                        there is a high turnover of members of the project (and perhaps I am
                        answering/or exposing a bigger problem). There is a loss of IP and
                        retionale for some of the decisions made. And thus there is a loss in
                        tracibility.

                        I feel that the Product Backlogs and Story Points are not enough to
                        address these issues. Has anyone else experieced anything similar or
                        have any suggestions to retain the intellectual property?


                      • Peter Hundermark
                        ... I find the responses posted by David H, Cheenie, Mike and Nicholas apt and helpful. I would add two thoughts: 1. Real documentation/traceability needs can
                        Message 11 of 11 , Jun 5 2:42 AM
                          --- In scrumdevelopment@yahoogroups.com, "Christiane Kuntz-Mayr"
                          <christiane.kuntz-mayr@...> wrote:
                          >
                          > Hi,
                          > we would like to exchange ideas how other companies ensure full
                          > implementation/tracebility of all selected requirements in Scrum
                          > projects:

                          I find the responses posted by David H, Cheenie, Mike and Nicholas
                          apt and helpful.

                          I would add two thoughts:

                          1. Real documentation/traceability needs can be addressed in the
                          team's definition of DONE. But this should not be allowed to become a
                          vehicle for the 'agile police' to hijack the project :-).

                          2. Alitair Cockburn has proposed: "Software development is a (series
                          of) cooperative game(s), in which people use markers and props to
                          inform, remind and inspire themselves and each other in getting to
                          the next move in the game. The endpoint of the game is an operating
                          software system; the residue of the game is a set of markers to
                          inform and assist the players of the next game. The next game is the
                          alteration or replacement of the system, or creation of a neighboring
                          system."
                          (http://alistair.cockburn.us/index.php/Cooperative_game_manifesto_for_
                          software_development)

                          It is often not easy to know what 'markers' to formalise and retain,
                          but IMO 'requirements' documents are neither necessary nor sufficient.

                          Peter
                        Your message has been successfully submitted and would be delivered to recipients shortly.