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

RE: [agile-usability] Re: Story Cards?

Expand Messages
  • Desilets, Alain
    Does it ever happen that a functionality that was designed and implemented in a particular way at an earlier point, needs to be re-worked in a major way,
    Message 1 of 21 , Mar 28 7:30 AM

      Does it ever happen that a functionality that was designed and implemented in a particular way at an earlier point, needs to be re-worked in  a major way, because the original design did not jive well with new functionality that was added?

       

      Alain

       

      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Scott Preece
      Sent: March 28, 2008 10:26 AM
      To: agile-usability@yahoogroups.com
      Subject: Re: [agile-usability] Re: Story Cards?

       

      Both - the *process* is iterative (you're cycling through the steps of figuring out, implementing, and validating), while the development itself is incremental (you're adding a little bit of functionality at each iterative).

      It's possible to be iterative without being incremental (where you're iterating around improvement, rather than added functionality). You could say that Waterfall is (or can be) incremental without being iterative - there's a single plan for adding the pieces one after another, as opposed to repeating the planning at each of a series of iterations.
       
      scott

      ----- Original Message ----
      From: "Desilets, Alain" <alain.desilets@...>
      To: agile-usability@yahoogroups.com
      Sent: Friday, March 28, 2008 8:45:11 AM
      Subject: RE: [agile-usability] Re: Story Cards?

      An interesting issue that keeps coming up is "incremental" vs
      "iterative". As Alistair Cockburn concisely puts it, Incremental means
      adding stuff, while Iterative means to redo stuff.

      When you say that the design is broken down and implemented in small
      chunks, would you say that you are thinking more along the lines of
      Incrementing or Iterating?

      Alain

      > -----Original Message-----
      > From: agile-usability@
      yahoogroups. com [mailto:agile-
      > usability@yahoogrou
      ps.com] On Behalf Of mitchgrrt
      > Sent: March 28, 2008 6:35 AM
      > To: agile-usability@
      yahoogroups. com
      > Subject: [agile-usability] Re: Story Cards?
      >
      > Interaction design needs to produce a design before engineers can
      > code. This seems a little bit to be against the philosophy of agile,
      > which is to do the work in little chunks rather than producing a big,
      > complete design in advance.
      >
      > How do we resolve this problem? It's not that hard, and it goes in
      > two steps. First, we make stories. For sprint 1, there is a story
      > like "produce interaction design for feature X, and review it with
      the
      > whole team". The story is assigned to an interaction designer and the
      > deliverables for the story are an agreed-upon design that is written
      > in some form that everybody on the project can understand. Then for
      > sprint 2, the story is "implement feature X using the design that was
      > produced in sprint 1". This works as long as the interaction
      > designers are always 1 sprint ahead of the engineers in the design
      > process.
      >
      > Second, we break it up into chunks. It's the agile idea of small,
      > deliverable, potentially shippable increments. So instead of one huge
      > design for all the features of the product, the design is broken into
      > smaller pieces. To do this the design team has to have a vision in
      > mind, and understand that the little pieces are converging on a bigger
      > vision. But the designs that are delivered to engineering are in
      > small pieces that can be implemented one sprint at a time.
      >
      > - Mitch Gart
      >
      >
      > ------------ --------- --------- ------
      >
      > Yahoo! Groups Links
      >
      >
      >

       

    • Scott Preece
      Sure - that s the result of the validating that I mentioned. The reason you re iterating is to reduce risk, by validating what you do in little pieces. That
      Message 2 of 21 , Mar 28 7:48 AM
        Sure - that's the result of the "validating" that I mentioned. The reason you're iterating is to reduce risk, by validating what you do in little pieces. That way you never go too far in the wrong direction. If something doesn't meet needs, or needs change, or new needs are recognized, you can rework what you did before. However, because you're doing it in little bits, the rework is usually narrower, rather than pervasive.

        scott

        ----- Original Message ----
        From: "Desilets, Alain" <alain.desilets@...>
        To: agile-usability@yahoogroups.com
        Sent: Friday, March 28, 2008 9:30:28 AM
        Subject: RE: [agile-usability] Re: Story Cards?

        Does it ever happen that a functionality that was designed and implemented in a particular way at an earlier point, needs to be re-worked in  a major way, because the original design did not jive well with new functionality that was added?

         

        Alain

         

        From: agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On Behalf Of Scott Preece
        Sent: March 28, 2008 10:26 AM
        To: agile-usability@ yahoogroups. com
        Subject: Re: [agile-usability] Re: Story Cards?

         

        Both - the *process* is iterative (you're cycling through the steps of figuring out, implementing, and validating), while the development itself is incremental (you're adding a little bit of functionality at each iterative).

        It's possible to be iterative without being incremental (where you're iterating around improvement, rather than added functionality) . You could say that Waterfall is (or can be) incremental without being iterative - there's a single plan for adding the pieces one after another, as opposed to repeating the planning at each of a series of iterations.
         
        scott

        ----- Original Message ----
        From: "Desilets, Alain" <alain.desilets@ nrc-cnrc. gc.ca>
        To: agile-usability@ yahoogroups. com
        Sent: Friday, March 28, 2008 8:45:11 AM
        Subject: RE: [agile-usability] Re: Story Cards?

        An interesting issue that keeps coming up is "incremental" vs
        "iterative". As Alistair Cockburn concisely puts it, Incremental means
        adding stuff, while Iterative means to redo stuff.

        When you say that the design is broken down and implemented in small
        chunks, would you say that you are thinking more along the lines of
        Incrementing or Iterating?

        Alain

        > -----Original Message-----
        > From: agile-usability@
        yahoogroups. com [mailto:agile-
        > usability@yahoogrou
        ps.com] On Behalf Of mitchgrrt
        > Sent: March 28, 2008 6:35 AM
        > To: agile-usability@
        yahoogroups. com
        > Subject: [agile-usability] Re: Story Cards?
        >
        > Interaction design needs to produce a design before engineers can
        > code. This seems a little bit to be against the philosophy of agile,
        > which is to do the work in little chunks rather than producing a big,
        > complete design in advance.
        >
        > How do we resolve this problem? It's not that hard, and it goes in
        > two steps. First, we make stories. For sprint 1, there is a story
        > like "produce interaction design for feature X, and review it with
        the
        > whole team". The story is assigned to an interaction designer and the
        > deliverables for the story are an agreed-upon design that is written
        > in some form that everybody on the project can understand. Then for
        > sprint 2, the story is "implement feature X using the design that was
        > produced in sprint 1". This works as long as the interaction
        > designers are always 1 sprint ahead of the engineers in the design
        > process.
        >
        > Second, we break it up into chunks. It's the agile idea of small,
        > deliverable, potentially shippable increments. So instead of one huge
        > design for all the features of the product, the design is broken into
        > smaller pieces. To do this the design team has to have a vision in
        > mind, and understand that the little pieces are converging on a bigger
        > vision. But the designs that are delivered to engineering are in
        > small pieces that can be implemented one sprint at a time.
        >
        > - Mitch Gart
        >
        >
        > ------------ --------- --------- ------
        >
        > Yahoo! Groups Links
        >
        >
        >

         


      • Desilets, Alain
        Thx. Is there documentation about how to do a server upgrade? All I could find was this procedure, but it seems to be for a first time install only:
        Message 3 of 21 , Mar 28 7:56 AM

          Thx.

           

          Is there documentation about how to do a server upgrade? All I could find was this procedure, but it seems to be for a first time install only:

           

          http://www.transana.org/support/MU-setup220_Server_Mac.htm

           

          Alain

           

          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Scott Preece
          Sent: March 28, 2008 10:26 AM
          To: agile-usability@yahoogroups.com
          Subject: Re: [agile-usability] Re: Story Cards?

           

          Both - the *process* is iterative (you're cycling through the steps of figuring out, implementing, and validating), while the development itself is incremental (you're adding a little bit of functionality at each iterative).

          It's possible to be iterative without being incremental (where you're iterating around improvement, rather than added functionality). You could say that Waterfall is (or can be) incremental without being iterative - there's a single plan for adding the pieces one after another, as opposed to repeating the planning at each of a series of iterations.
           
          scott

          ----- Original Message ----
          From: "Desilets, Alain" <alain.desilets@...>
          To: agile-usability@yahoogroups.com
          Sent: Friday, March 28, 2008 8:45:11 AM
          Subject: RE: [agile-usability] Re: Story Cards?

          An interesting issue that keeps coming up is "incremental" vs
          "iterative". As Alistair Cockburn concisely puts it, Incremental means
          adding stuff, while Iterative means to redo stuff.

          When you say that the design is broken down and implemented in small
          chunks, would you say that you are thinking more along the lines of
          Incrementing or Iterating?

          Alain

          > -----Original Message-----
          > From: agile-usability@
          yahoogroups. com [mailto:agile-
          > usability@yahoogrou
          ps.com] On Behalf Of mitchgrrt
          > Sent: March 28, 2008 6:35 AM
          > To: agile-usability@
          yahoogroups. com
          > Subject: [agile-usability] Re: Story Cards?
          >
          > Interaction design needs to produce a design before engineers can
          > code. This seems a little bit to be against the philosophy of agile,
          > which is to do the work in little chunks rather than producing a big,
          > complete design in advance.
          >
          > How do we resolve this problem? It's not that hard, and it goes in
          > two steps. First, we make stories. For sprint 1, there is a story
          > like "produce interaction design for feature X, and review it with
          the
          > whole team". The story is assigned to an interaction designer and the
          > deliverables for the story are an agreed-upon design that is written
          > in some form that everybody on the project can understand. Then for
          > sprint 2, the story is "implement feature X using the design that was
          > produced in sprint 1". This works as long as the interaction
          > designers are always 1 sprint ahead of the engineers in the design
          > process.
          >
          > Second, we break it up into chunks. It's the agile idea of small,
          > deliverable, potentially shippable increments. So instead of one huge
          > design for all the features of the product, the design is broken into
          > smaller pieces. To do this the design team has to have a vision in
          > mind, and understand that the little pieces are converging on a bigger
          > vision. But the designs that are delivered to engineering are in
          > small pieces that can be implemented one sprint at a time.
          >
          > - Mitch Gart
          >
          >
          > ------------ --------- --------- ------
          >
          > Yahoo! Groups Links
          >
          >
          >

           

        • Desilets, Alain
          Oops. Bad address. Sorry folks. From: Desilets, Alain Sent: March 28, 2008 10:57 AM To: agile-usability@yahoogroups.com Subject: RE: [agile-usability] Re:
          Message 4 of 21 , Mar 28 8:06 AM

            Oops. Bad address. Sorry folks.

             

            From: Desilets, Alain
            Sent: March 28, 2008 10:57 AM
            To: 'agile-usability@yahoogroups.com'
            Subject: RE: [agile-usability] Re: Story Cards?

             

            Thx.

             

            Is there documentation about how to do a server upgrade? All I could find was this procedure, but it seems to be for a first time install only:

             

            http://www.transana.org/support/MU-setup220_Server_Mac.htm

             

            Alain

             

            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Scott Preece
            Sent: March 28, 2008 10:26 AM
            To: agile-usability@yahoogroups.com
            Subject: Re: [agile-usability] Re: Story Cards?

             

            Both - the *process* is iterative (you're cycling through the steps of figuring out, implementing, and validating), while the development itself is incremental (you're adding a little bit of functionality at each iterative).

            It's possible to be iterative without being incremental (where you're iterating around improvement, rather than added functionality). You could say that Waterfall is (or can be) incremental without being iterative - there's a single plan for adding the pieces one after another, as opposed to repeating the planning at each of a series of iterations.
             
            scott

            ----- Original Message ----
            From: "Desilets, Alain" <alain.desilets@...>
            To: agile-usability@yahoogroups.com
            Sent: Friday, March 28, 2008 8:45:11 AM
            Subject: RE: [agile-usability] Re: Story Cards?

            An interesting issue that keeps coming up is "incremental" vs
            "iterative". As Alistair Cockburn concisely puts it, Incremental means
            adding stuff, while Iterative means to redo stuff.

            When you say that the design is broken down and implemented in small
            chunks, would you say that you are thinking more along the lines of
            Incrementing or Iterating?

            Alain

            > -----Original Message-----
            > From: agile-usability@
            yahoogroups. com [mailto:agile-
            > usability@yahoogrou
            ps.com] On Behalf Of mitchgrrt
            > Sent: March 28, 2008 6:35 AM
            > To: agile-usability@
            yahoogroups. com
            > Subject: [agile-usability] Re: Story Cards?
            >
            > Interaction design needs to produce a design before engineers can
            > code. This seems a little bit to be against the philosophy of agile,
            > which is to do the work in little chunks rather than producing a big,
            > complete design in advance.
            >
            > How do we resolve this problem? It's not that hard, and it goes in
            > two steps. First, we make stories. For sprint 1, there is a story
            > like "produce interaction design for feature X, and review it with
            the
            > whole team". The story is assigned to an interaction designer and the
            > deliverables for the story are an agreed-upon design that is written
            > in some form that everybody on the project can understand. Then for
            > sprint 2, the story is "implement feature X using the design that was
            > produced in sprint 1". This works as long as the interaction
            > designers are always 1 sprint ahead of the engineers in the design
            > process.
            >
            > Second, we break it up into chunks. It's the agile idea of small,
            > deliverable, potentially shippable increments. So instead of one huge
            > design for all the features of the product, the design is broken into
            > smaller pieces. To do this the design team has to have a vision in
            > mind, and understand that the little pieces are converging on a bigger
            > vision. But the designs that are delivered to engineering are in
            > small pieces that can be implemented one sprint at a time.
            >
            > - Mitch Gart
            >
            >
            > ------------ --------- --------- ------
            >
            > Yahoo! Groups Links
            >
            >
            >

             

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