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

Re: [scrumdevelopment] Re: Tracebility

Expand Messages
  • 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 1 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 2 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 3 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.