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

Re: [scrumdevelopment] Re: Tracebility

Expand Messages
  • 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 1 of 11 , May 31, 2007
    • 0 Attachment
      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 2 of 11 , Jun 1, 2007
      • 0 Attachment
        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 3 of 11 , Jun 4, 2007
        • 0 Attachment
          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 4 of 11 , Jun 4, 2007
          • 0 Attachment

            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 5 of 11 , Jun 5, 2007
            • 0 Attachment
              --- 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.