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

Story Cards?

Expand Messages
  • careycaulfield
    Hello All So, anyone else doing Story Cards ? Do they work for you in working/communicating more efficiently with developers? From what I m reading (at the
    Message 1 of 21 , Mar 24, 2008
      Hello All

      So, anyone else doing "Story Cards"?

      Do they work for you in working/communicating more efficiently with
      developers?

      From what I'm reading (at the agilealliance and getting the User
      Stories Applied book today) these are hard copy index cards with
      maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
      hard copy. Is that correct? I will definitely want to do these in an
      Online Format like in Fireworks or Visio. Or some tool for maintaining
      these. Thoughts?

      Thanks in advance for your help!
      Carey

      PS: Background: In our engineering team, we just moved to Scrum after
      doing RUP for many years. As a UX designer, I wrote, wireframes and
      mockup'd lots of up front Word doc specifications. Our goal is to
      really move away from that. Thanks.
    • Kelly Waters
      Hi Carey Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as
      Message 2 of 21 , Mar 25, 2008
        Hi Carey
         
        Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
         
        I've posted an example of a User Story card here:
         
         
        This was produced in Visio and printed onto a postcard for use on the team's whiteboard...
         
        Kelly Waters
         
         


         
        On 24/03/2008, careycaulfield <carey.caulfield@...> wrote:

        Hello All

        So, anyone else doing "Story Cards"?

        Do they work for you in working/communicating more efficiently with
        developers?

        From what I'm reading (at the agilealliance and getting the User
        Stories Applied book today) these are hard copy index cards with
        maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
        hard copy. Is that correct? I will definitely want to do these in an
        Online Format like in Fireworks or Visio. Or some tool for maintaining
        these. Thoughts?

        Thanks in advance for your help!
        Carey

        PS: Background: In our engineering team, we just moved to Scrum after
        doing RUP for many years. As a UX designer, I wrote, wireframes and
        mockup'd lots of up front Word doc specifications. Our goal is to
        really move away from that. Thanks.


      • Olivier Van Acker
        Hi, User stories for us have been very helpful to get the conversation going between the business analyst and the developers. It has been an invaluable tool to
        Message 3 of 21 , Mar 25, 2008

          Hi,

           

          User stories for us have been very helpful to get the conversation going between the business analyst and the developers. It has been an invaluable tool to get the development process less ‘paper’ and more ‘conversation’ driven. Ideally the business analyst explains the requirement (user story) just before the developer start implementing it. A few mockups won’t harm of course as long as you keep in mind that ‘conversation’ is the main goal of this tool.

           

          What I found very helpful is the following format:

           

          As a [Who]

          I want [What]

          So that [Why]

           

          [Who] can be any user role like system administrator, data entry person, ceo, client, etc

          [What] is what they want of this new system

          [Why] what is the reason behind this

           

          Especially the why bit is extremely useful because it forces people to think on how important/significant a specific user story/requirement is. (Is it really that important?) This also has helped us a lot in the prioritization of the requirements.

           

          So this who/what/why format together with more conversation and less paper has made our development process more energetic, got the business more involved in the development and it helped us focus more on the important bits of the requirements.

           

          Hope this helped,

           

          Regards,

           

           

          Olivier

           


          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of careycaulfield
          Sent: Monday, March 24, 2008 8:49 PM
          To: agile-usability@yahoogroups.com
          Subject: [agile-usability] Story Cards?

           

          Hello All

          So, anyone else doing "Story Cards"?

          Do they work for you in working/communicati ng more efficiently with
          developers?

          From what I'm reading (at the agilealliance and getting the User
          Stories Applied book today) these are hard copy index cards with
          maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
          hard copy. Is that correct? I will definitely want to do these in an
          Online Format like in Fireworks or Visio. Or some tool for maintaining
          these. Thoughts?

          Thanks in advance for your help!
          Carey

          PS: Background: In our engineering team, we just moved to Scrum after
          doing RUP for many years. As a UX designer, I wrote, wireframes and
          mockup'd lots of up front Word doc specifications. Our goal is to
          really move away from that. Thanks.



          YouthNet UK is a limited company registered in England and Wales. Company registration number: 3031098. Charity registration number 1048995. Registered office: 100 Victoria Embankment, London, EC4Y 0DH.
        • William Pietri
          Hi, Kelly. I really like your use of mini-wireframes as a good way to communicate from designer to developer. (I like paper prototypes and whiteboard sketches,
          Message 4 of 21 , Mar 25, 2008
            Hi, Kelly. I really like your use of mini-wireframes as a good way to communicate from designer to developer. (I like paper prototypes and whiteboard sketches, too; they aren't as pretty, but they are a more collaborative medium.) And I like that you've found a way to keep a sketch with the story; that would be especially handy for outsiders, who can find cards a little cryptic.

            I'm concerned, though, that you refer to laser-printed requirements as the "conversation" part of "Card, Conversation, Confirmation". As far as I know, Ron Jeffries is the person who coined that phrase:

            http://www.xprogramming.com/xpmag/expCardConversationConfirmation.htm

            Like him, I think actual human conversation, where a cross-functional group of people talk over the story, is vital to an agile process. I assume you must mean that the "conversation" part of the card is a record of conversations had. But from your post, I worry that people could get the idea that the agile notion of "conversation" is person A printing something and handing it to to person B, when the exact opposite is true.

            In my view, although an easily digestible specification is still better than a typical one, it won't deliver the full value of agile methods. To do that, you need cross-functional teams collaborating, rather than the one-way communication that a printed spec implies.

            To force that discussion, I strongly recommend teams new to agile methods put the absolute minimum on a card to start with, perhaps 5-10 words. It should be just enough to identify the unit of work, but not enough to explain it. As a sharp fellow once said to me, "If people say they are having a hard time fitting everything on the card, then give them smaller cards and bigger markers."

            William



            Kelly Waters wrote:
            Hi Carey
             
            Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
             
            I've posted an example of a User Story card here:
             
             
            This was produced in Visio and printed onto a postcard for use on the team's whiteboard...
             
            Kelly Waters
             
             


             
            On 24/03/2008, careycaulfield <carey.caulfield@...> wrote:

            Hello All

            So, anyone else doing "Story Cards"?

            Do they work for you in working/communicating more efficiently with
            developers?

            From what I'm reading (at the agilealliance and getting the User
            Stories Applied book today) these are hard copy index cards with
            maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
            hard copy. Is that correct? I will definitely want to do these in an
            Online Format like in Fireworks or Visio. Or some tool for maintaining
            these. Thoughts?

            Thanks in advance for your help!
            Carey

            PS: Background: In our engineering team, we just moved to Scrum after
            doing RUP for many years. As a UX designer, I wrote, wireframes and
            mockup'd lots of up front Word doc specifications. Our goal is to
            really move away from that. Thanks.



          • Scott Preece
            I like this a lot, coming from a background of long visual specs that are hard to condense to a clear picture of what s intended. How do you address cases
            Message 5 of 21 , Mar 25, 2008
              I like this a lot, coming from a background of long visual specs that are hard to condense to a clear picture of what's intended. How do you address cases where you break a story down and want to present just a single feature accessed within a more complex context (that is, where the visual has to isolate the bits that make up the story, while not getting caught up in the rest of the options?

              On the other hand, I'd be perfectly happy to see it as an online card, allowing links to additional material. I work in a distributed team, so physical artifacts are less interesting to me.

              thanks,
              scott

              ----- Original Message ----
              From: Kelly Waters <allaboutagile@...>
              To: agile-usability@yahoogroups.com
              Sent: Tuesday, March 25, 2008 2:17:59 AM
              Subject: Re: [agile-usability] Story Cards?

              Hi Carey
               
              Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
               
              I've posted an example of a User Story card here:
               
               
              This was produced in Visio and printed onto a postcard for use on the team's whiteboard.. .
               
              Kelly Waters
               
               


               
              On 24/03/2008, careycaulfield <carey.caulfield@ citrix.com> wrote:

              Hello All

              So, anyone else doing "Story Cards"?

              Do they work for you in working/communicati ng more efficiently with
              developers?

              From what I'm reading (at the agilealliance and getting the User
              Stories Applied book today) these are hard copy index cards with
              maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
              hard copy. Is that correct? I will definitely want to do these in an
              Online Format like in Fireworks or Visio. Or some tool for maintaining
              these. Thoughts?

              Thanks in advance for your help!
              Carey

              PS: Background: In our engineering team, we just moved to Scrum after
              doing RUP for many years. As a UX designer, I wrote, wireframes and
              mockup'd lots of up front Word doc specifications. Our goal is to
              really move away from that. Thanks.



            • Carey Caulfield
              Hi Kelly and all Thanks for your responses about Story Cards. I think I ve got it. Plan is to create a wiki page per user story with a picture. I will do these
              Message 6 of 21 , Mar 25, 2008
                Hi Kelly and all
                 
                Thanks for your responses about Story Cards. I think I've got it. Plan is to create a wiki page per user story with a picture. I will do these 2 sprints ahead of the dev team.
                 
                So how do you then communicate the final visual design or all the little nuances? When does that step come to play?
                 
                Thanks again,
                Carey
                 
                 


                From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Kelly Waters
                Sent: Tuesday, March 25, 2008 12:18 AM
                To: agile-usability@yahoogroups.com
                Subject: Re: [agile-usability] Story Cards?

                Hi Carey
                 
                Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
                 
                I've posted an example of a User Story card here:
                 
                 
                This was produced in Visio and printed onto a postcard for use on the team's whiteboard.. .
                 
                Kelly Waters
                 
                 


                 
                On 24/03/2008, careycaulfield <carey.caulfield@ citrix.com> wrote:

                Hello All

                So, anyone else doing "Story Cards"?

                Do they work for you in working/communicati ng more efficiently with
                developers?

                From what I'm reading (at the agilealliance and getting the User
                Stories Applied book today) these are hard copy index cards with
                maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
                hard copy. Is that correct? I will definitely want to do these in an
                Online Format like in Fireworks or Visio. Or some tool for maintaining
                these. Thoughts?

                Thanks in advance for your help!
                Carey

                PS: Background: In our engineering team, we just moved to Scrum after
                doing RUP for many years. As a UX designer, I wrote, wireframes and
                mockup'd lots of up front Word doc specifications. Our goal is to
                really move away from that. Thanks.


              • William Pietri
                Hi, Carey. Could you say more about your circumstances? Is this a distributed team, or are you folks in the same building? Thanks, William
                Message 7 of 21 , Mar 25, 2008
                  Hi, Carey. Could you say more about your circumstances? Is this a distributed team, or are you folks in the same building?

                  Thanks,

                  William

                  Carey Caulfield wrote:
                  Hi Kelly and all
                   
                  Thanks for your responses about Story Cards. I think I've got it. Plan is to create a wiki page per user story with a picture. I will do these 2 sprints ahead of the dev team.
                   
                  So how do you then communicate the final visual design or all the little nuances? When does that step come to play?
                   
                  Thanks again,
                  Carey
                   
                   


                  From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Kelly Waters
                  Sent: Tuesday, March 25, 2008 12:18 AM
                  To: agile-usability@yahoogroups.com
                  Subject: Re: [agile-usability] Story Cards?

                  Hi Carey
                   
                  Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
                   
                  I've posted an example of a User Story card here:
                   
                   
                  This was produced in Visio and printed onto a postcard for use on the team's whiteboard.. .
                   
                  Kelly Waters
                   
                   


                   
                  On 24/03/2008, careycaulfield <carey.caulfield@ citrix.com> wrote:

                  Hello All

                  So, anyone else doing "Story Cards"?

                  Do they work for you in working/communicati ng more efficiently with
                  developers?

                  From what I'm reading (at the agilealliance and getting the User
                  Stories Applied book today) these are hard copy index cards with
                  maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
                  hard copy. Is that correct? I will definitely want to do these in an
                  Online Format like in Fireworks or Visio. Or some tool for maintaining
                  these. Thoughts?

                  Thanks in advance for your help!
                  Carey

                  PS: Background: In our engineering team, we just moved to Scrum after
                  doing RUP for many years. As a UX designer, I wrote, wireframes and
                  mockup'd lots of up front Word doc specifications. Our goal is to
                  really move away from that. Thanks.



                • Carey Caulfield
                  Hi William. Sure thing. We are all in the same building, although I and a few others do work remote 3 days a week. We have daily stand-ups. We do not all
                  Message 8 of 21 , Mar 25, 2008
                    Hi William. Sure thing. We are all in the same building, although I and a few others do work remote 3 days a week. We have daily stand-ups. We do not all currently sit together however. Dev is on one side of building, QA downstairs and I sit in the UX wing.
                     
                    Additionally we have backend developers do most of the heavy coding, then when they are done a front end coder (HTML, JavaScript) comes along and updates the pages according to our mockups. (At least that's how it's worked in the past.)


                    From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of William Pietri
                    Sent: Tuesday, March 25, 2008 3:19 PM
                    To: agile-usability@yahoogroups.com
                    Subject: Re: [agile-usability] Story Cards?

                    Hi, Carey. Could you say more about your circumstances? Is this a distributed team, or are you folks in the same building?

                    Thanks,

                    William

                    Carey Caulfield wrote:

                    Hi Kelly and all
                     
                    Thanks for your responses about Story Cards. I think I've got it. Plan is to create a wiki page per user story with a picture. I will do these 2 sprints ahead of the dev team.
                     
                    So how do you then communicate the final visual design or all the little nuances? When does that step come to play?
                     
                    Thanks again,
                    Carey
                     
                     


                    From: agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On Behalf Of Kelly Waters
                    Sent: Tuesday, March 25, 2008 12:18 AM
                    To: agile-usability@ yahoogroups. com
                    Subject: Re: [agile-usability] Story Cards?

                    Hi Carey
                     
                    Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
                     
                    I've posted an example of a User Story card here:
                     
                     
                    This was produced in Visio and printed onto a postcard for use on the team's whiteboard.. .
                     
                    Kelly Waters
                     
                     


                     
                    On 24/03/2008, careycaulfield <carey.caulfield@ citrix.com> wrote:

                    Hello All

                    So, anyone else doing "Story Cards"?

                    Do they work for you in working/communicati ng more efficiently with
                    developers?

                    From what I'm reading (at the agilealliance and getting the User
                    Stories Applied book today) these are hard copy index cards with
                    maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
                    hard copy. Is that correct? I will definitely want to do these in an
                    Online Format like in Fireworks or Visio. Or some tool for maintaining
                    these. Thoughts?

                    Thanks in advance for your help!
                    Carey

                    PS: Background: In our engineering team, we just moved to Scrum after
                    doing RUP for many years. As a UX designer, I wrote, wireframes and
                    mockup'd lots of up front Word doc specifications. Our goal is to
                    really move away from that. Thanks.



                  • Kelly Waters
                    Hi Carey If you re using Scrum, you clarify requirements as a team in the first part of Sprint Planning, just before you embark on the Sprint. In the second
                    Message 9 of 21 , Mar 25, 2008
                      Hi Carey
                       
                      If you're using Scrum, you clarify requirements as a team in the first part of Sprint Planning, just before you embark on the Sprint.  In the second part of Sprint Planning, you break the stories into tasks and estimate them.
                       
                      I wrote a series of blog posts about how to implement Scrum, in which I describe this process here...
                       
                       
                      Regards
                       
                      Kelly.
                       
                       
                      Kelly Waters

                       
                      On 25/03/2008, Carey Caulfield <carey.caulfield@...> wrote:

                      Hi Kelly and all
                       
                      Thanks for your responses about Story Cards. I think I've got it. Plan is to create a wiki page per user story with a picture. I will do these 2 sprints ahead of the dev team.
                       
                      So how do you then communicate the final visual design or all the little nuances? When does that step come to play?
                       
                      Thanks again,
                      Carey
                       
                       


                      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Kelly Waters
                      Sent: Tuesday, March 25, 2008 12:18 AM
                      To: agile-usability@yahoogroups.com
                      Subject: Re: [agile-usability] Story Cards?

                       

                      Hi Carey
                       
                      Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
                       
                      I've posted an example of a User Story card here:
                       
                       
                      This was produced in Visio and printed onto a postcard for use on the team's whiteboard...
                       
                      Kelly Waters
                       
                       


                       
                      On 24/03/2008, careycaulfield <carey.caulfield@...> wrote:

                      Hello All

                      So, anyone else doing "Story Cards"?

                      Do they work for you in working/communicating more efficiently with
                      developers?

                      From what I'm reading (at the agilealliance and getting the User
                      Stories Applied book today) these are hard copy index cards with
                      maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
                      hard copy. Is that correct? I will definitely want to do these in an
                      Online Format like in Fireworks or Visio. Or some tool for maintaining
                      these. Thoughts?

                      Thanks in advance for your help!
                      Carey

                      PS: Background: In our engineering team, we just moved to Scrum after
                      doing RUP for many years. As a UX designer, I wrote, wireframes and
                      mockup'd lots of up front Word doc specifications. Our goal is to
                      really move away from that. Thanks.



                    • William Pietri
                      In that case, a wiki seems like a good compromise. Be aware that physical artifacts in shared spaces have a number of strengths that are not easily achieved on
                      Message 10 of 21 , Mar 25, 2008
                        In that case, a wiki seems like a good compromise. Be aware that physical artifacts in shared spaces have a number of strengths that are not easily achieved on line, so you may struggle to make this work. As much as possible, I'd encourage you to use the wiki as a place to take notes on conversations that happen in real time, rather than as a medium for discussion.

                        More generally, you should be aware that spreading a team out like that is an agile adoption antipattern. Some people make it work, but it is harder and more prone to failure than physical collocation. If you find the team struggling or not getting the value expected out of agile practices, I'd suggest you collectively revisit that decision.

                        William

                        P.S. My number one trick to get people actually using wikis is to make obvious omissions and leave little mistakes. This can be very hard to do, but my general experience with intranet wikis is that if I am the only one writing it, I will be the only one reading it. Come to think of it, it's the same way with physical cards, so there's probably a deeper principle at work here.


                        Carey Caulfield wrote:
                        Hi William. Sure thing. We are all in the same building, although I and a few others do work remote 3 days a week. We have daily stand-ups. We do not all currently sit together however. Dev is on one side of building, QA downstairs and I sit in the UX wing.
                         
                        Additionally we have backend developers do most of the heavy coding, then when they are done a front end coder (HTML, JavaScript) comes along and updates the pages according to our mockups. (At least that's how it's worked in the past.)


                        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of William Pietri
                        Sent: Tuesday, March 25, 2008 3:19 PM
                        To: agile-usability@yahoogroups.com
                        Subject: Re: [agile-usability] Story Cards?

                        Hi, Carey. Could you say more about your circumstances? Is this a distributed team, or are you folks in the same building?

                        Thanks,

                        William

                        Carey Caulfield wrote:

                        Hi Kelly and all
                         
                        Thanks for your responses about Story Cards. I think I've got it. Plan is to create a wiki page per user story with a picture. I will do these 2 sprints ahead of the dev team.
                         
                        So how do you then communicate the final visual design or all the little nuances? When does that step come to play?
                         
                        Thanks again,
                        Carey
                         
                         


                        From: agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On Behalf Of Kelly Waters
                        Sent: Tuesday, March 25, 2008 12:18 AM
                        To: agile-usability@ yahoogroups. com
                        Subject: Re: [agile-usability] Story Cards?

                        Hi Carey
                         
                        Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
                         
                        I've posted an example of a User Story card here:
                         
                         
                        This was produced in Visio and printed onto a postcard for use on the team's whiteboard.. .
                         
                        Kelly Waters
                         
                         


                         
                        On 24/03/2008, careycaulfield <carey.caulfield@ citrix.com> wrote:

                        Hello All

                        So, anyone else doing "Story Cards"?

                        Do they work for you in working/communicati ng more efficiently with
                        developers?

                        From what I'm reading (at the agilealliance and getting the User
                        Stories Applied book today) these are hard copy index cards with
                        maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
                        hard copy. Is that correct? I will definitely want to do these in an
                        Online Format like in Fireworks or Visio. Or some tool for maintaining
                        these. Thoughts?

                        Thanks in advance for your help!
                        Carey

                        PS: Background: In our engineering team, we just moved to Scrum after
                        doing RUP for many years. As a UX designer, I wrote, wireframes and
                        mockup'd lots of up front Word doc specifications. Our goal is to
                        really move away from that. Thanks.




                    • Carey Caulfield
                      Hi Kelly Yes, I guess this is the sticky part. For the last year we were doing RUP on this product, so I and a few other UX designers had to write the detailed
                      Message 11 of 21 , Mar 25, 2008
                        Hi Kelly
                         
                        Yes, I guess this is the sticky part. For the last year we were doing RUP on this product, so I and a few other UX designers had to write the detailed specifications for every feature. So we have the specifications, the mockups, pretty much everything. Development has even coded a fair amount of everything with nothing really "done" at all. Dev was running into all kinds of technical issues that weren't being resolved fast enough. Anyway, we basically moved to Scrum mid-development after other product teams were having a lot of success with it.
                         
                        So I guess our product is in a bit of a hybrid stage currently. Sorry all for going on. Perhaps others can relate to this. Having done the lengthy specification thing for the last 5 years, I can tell you I think it will be a much more pleasant experience this go around. Fingers crossed. :)
                         
                        Carey


                        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Kelly Waters
                        Sent: Tuesday, March 25, 2008 3:23 PM
                        To: agile-usability@yahoogroups.com
                        Subject: Re: [agile-usability] Story Cards?

                        Hi Carey
                         
                        If you're using Scrum, you clarify requirements as a team in the first part of Sprint Planning, just before you embark on the Sprint.  In the second part of Sprint Planning, you break the stories into tasks and estimate them.
                         
                        I wrote a series of blog posts about how to implement Scrum, in which I describe this process here...
                         
                         
                        Regards
                         
                        Kelly.
                         
                         
                        Kelly Waters

                         
                        On 25/03/2008, Carey Caulfield <carey.caulfield@ citrix.com> wrote:

                        Hi Kelly and all
                         
                        Thanks for your responses about Story Cards. I think I've got it. Plan is to create a wiki page per user story with a picture. I will do these 2 sprints ahead of the dev team.
                         
                        So how do you then communicate the final visual design or all the little nuances? When does that step come to play?
                         
                        Thanks again,
                        Carey
                         
                         


                        From: agile-usability@ yahoogroups. com [mailto:agile-usability@ yahoogroups. com] On Behalf Of Kelly Waters
                        Sent: Tuesday, March 25, 2008 12:18 AM
                        To: agile-usability@ yahoogroups. com
                        Subject: Re: [agile-usability] Story Cards?

                         

                        Hi Carey
                         
                        Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
                         
                        I've posted an example of a User Story card here:
                         
                         
                        This was produced in Visio and printed onto a postcard for use on the team's whiteboard.. .
                         
                        Kelly Waters
                         
                         


                         
                        On 24/03/2008, careycaulfield <carey.caulfield@ citrix.com> wrote:

                        Hello All

                        So, anyone else doing "Story Cards"?

                        Do they work for you in working/communicati ng more efficiently with
                        developers?

                        From what I'm reading (at the agilealliance and getting the User
                        Stories Applied book today) these are hard copy index cards with
                        maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
                        hard copy. Is that correct? I will definitely want to do these in an
                        Online Format like in Fireworks or Visio. Or some tool for maintaining
                        these. Thoughts?

                        Thanks in advance for your help!
                        Carey

                        PS: Background: In our engineering team, we just moved to Scrum after
                        doing RUP for many years. As a UX designer, I wrote, wireframes and
                        mockup'd lots of up front Word doc specifications. Our goal is to
                        really move away from that. Thanks.



                      • PPWilliamson
                        Kelly! What a great Blog, this is very, very useful for me. I needed a refresher on Sprint Planning, very nice! :-) Carey Caulfield
                        Message 12 of 21 , Mar 27, 2008
                          Kelly! What a great Blog, this is very, very useful for me. I needed a refresher on Sprint Planning, very nice! :-)

                          Carey Caulfield <carey.caulfield@...> wrote:
                          Hi Kelly
                           
                          Yes, I guess this is the sticky part. For the last year we were doing RUP on this product, so I and a few other UX designers had to write the detailed specifications for every feature. So we have the specifications, the mockups, pretty much everything. Development has even coded a fair amount of everything with nothing really "done" at all. Dev was running into all kinds of technical issues that weren't being resolved fast enough. Anyway, we basically moved to Scrum mid-development after other product teams were having a lot of success with it.
                           
                          So I guess our product is in a bit of a hybrid stage currently. Sorry all for going on. Perhaps others can relate to this. Having done the lengthy specification thing for the last 5 years, I can tell you I think it will be a much more pleasant experience this go around. Fingers crossed. :)
                           
                          Carey


                          From: agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On Behalf Of Kelly Waters
                          Sent: Tuesday, March 25, 2008 3:23 PM
                          To: agile-usability@ yahoogroups. com
                          Subject: Re: [agile-usability] Story Cards?

                          Hi Carey
                           
                          If you're using Scrum, you clarify requirements as a team in the first part of Sprint Planning, just before you embark on the Sprint.  In the second part of Sprint Planning, you break the stories into tasks and estimate them.
                           
                          I wrote a series of blog posts about how to implement Scrum, in which I describe this process here...
                           
                           
                          Regards
                           
                          Kelly.
                           
                           
                          Kelly Waters

                           
                          On 25/03/2008, Carey Caulfield <carey.caulfield@ citrix.com> wrote:
                          Hi Kelly and all
                           
                          Thanks for your responses about Story Cards. I think I've got it. Plan is to create a wiki page per user story with a picture. I will do these 2 sprints ahead of the dev team.
                           
                          So how do you then communicate the final visual design or all the little nuances? When does that step come to play?
                           
                          Thanks again,
                          Carey
                           
                           


                          From: agile-usability@ yahoogroups. com [mailto:agile-usability@ yahoogroups. com] On Behalf Of Kelly Waters
                          Sent: Tuesday, March 25, 2008 12:18 AM
                          To: agile-usability@ yahoogroups. com
                          Subject: Re: [agile-usability] Story Cards?

                           
                          Hi Carey
                           
                          Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
                           
                          I've posted an example of a User Story card here:
                           
                           
                          This was produced in Visio and printed onto a postcard for use on the team's whiteboard.. .
                           
                          Kelly Waters
                           
                           


                           
                          On 24/03/2008, careycaulfield <carey.caulfield@ citrix.com> wrote:
                          Hello All

                          So, anyone else doing "Story Cards"?

                          Do they work for you in working/communicati ng more efficiently with
                          developers?

                          From what I'm reading (at the agilealliance and getting the User
                          Stories Applied book today) these are hard copy index cards with
                          maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
                          hard copy. Is that correct? I will definitely want to do these in an
                          Online Format like in Fireworks or Visio. Or some tool for maintaining
                          these. Thoughts?

                          Thanks in advance for your help!
                          Carey

                          PS: Background: In our engineering team, we just moved to Scrum after
                          doing RUP for many years. As a UX designer, I wrote, wireframes and
                          mockup'd lots of up front Word doc specifications. Our goal is to
                          really move away from that. Thanks.






                          "Once you've ruined your reputation, you can live life quite freely."


                          Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

                        • Kelly Waters
                          Thanks for the feedback, it s very much appreciated and I m glad you re finding my blog useful. Kind regards Kelly. Kelly Waters www.allaboutagile.com
                          Message 13 of 21 , Mar 27, 2008
                            Thanks for the feedback, it's very much appreciated and I'm glad you're finding my blog useful.
                             
                            Kind regards
                             
                            Kelly.
                             

                            Kelly Waters


                             
                            On 27/03/2008, PPWilliamson <freehandpowers@...> wrote:

                            Kelly! What a great Blog, this is very, very useful for me. I needed a refresher on Sprint Planning, very nice! :-)

                            Carey Caulfield <carey.caulfield@...> wrote:

                            Hi Kelly
                             
                            Yes, I guess this is the sticky part. For the last year we were doing RUP on this product, so I and a few other UX designers had to write the detailed specifications for every feature. So we have the specifications, the mockups, pretty much everything. Development has even coded a fair amount of everything with nothing really "done" at all. Dev was running into all kinds of technical issues that weren't being resolved fast enough. Anyway, we basically moved to Scrum mid-development after other product teams were having a lot of success with it.
                             
                            So I guess our product is in a bit of a hybrid stage currently. Sorry all for going on. Perhaps others can relate to this. Having done the lengthy specification thing for the last 5 years, I can tell you I think it will be a much more pleasant experience this go around. Fingers crossed. :)
                             
                            Carey


                            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Kelly Waters
                            Sent: Tuesday, March 25, 2008 3:23 PM
                            To: agile-usability@yahoogroups.com
                            Subject: Re: [agile-usability] Story Cards?

                             
                            Hi Carey
                             
                            If you're using Scrum, you clarify requirements as a team in the first part of Sprint Planning, just before you embark on the Sprint.  In the second part of Sprint Planning, you break the stories into tasks and estimate them.
                             
                            I wrote a series of blog posts about how to implement Scrum, in which I describe this process here...
                             
                             
                            Regards
                             
                            Kelly.
                             
                             
                            Kelly Waters

                             
                            On 25/03/2008, Carey Caulfield <carey.caulfield@...> wrote:
                            Hi Kelly and all
                             
                            Thanks for your responses about Story Cards. I think I've got it. Plan is to create a wiki page per user story with a picture. I will do these 2 sprints ahead of the dev team.
                             
                            So how do you then communicate the final visual design or all the little nuances? When does that step come to play?
                             
                            Thanks again,
                            Carey
                             
                             


                            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Kelly Waters
                            Sent: Tuesday, March 25, 2008 12:18 AM
                            To: agile-usability@yahoogroups.com
                            Subject: Re: [agile-usability] Story Cards?

                             
                            Hi Carey
                             
                            Personally I like to combine the visual nature of wireframes and storyboards with the principle of writing lightweight requirements as User Stories as near as possible to the time of development.
                             
                            I've posted an example of a User Story card here:
                             
                             
                            This was produced in Visio and printed onto a postcard for use on the team's whiteboard...
                             
                            Kelly Waters
                             
                             


                             
                            On 24/03/2008, careycaulfield <carey.caulfield@...> wrote:
                            Hello All

                            So, anyone else doing "Story Cards"?

                            Do they work for you in working/communicating more efficiently with
                            developers?

                            From what I'm reading (at the agilealliance and getting the User
                            Stories Applied book today) these are hard copy index cards with
                            maybe, a picture (wireframe? Or full fledged mockup?) on them. Yikes
                            hard copy. Is that correct? I will definitely want to do these in an
                            Online Format like in Fireworks or Visio. Or some tool for maintaining
                            these. Thoughts?

                            Thanks in advance for your help!
                            Carey

                            PS: Background: In our engineering team, we just moved to Scrum after
                            doing RUP for many years. As a UX designer, I wrote, wireframes and
                            mockup'd lots of up front Word doc specifications. Our goal is to
                            really move away from that. Thanks.

                             





                            "Once you've ruined your reputation, you can live life quite freely."


                            Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.


                          • mitchgrrt
                            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
                            Message 14 of 21 , Mar 28, 2008
                              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
                            • Desilets, Alain
                              An interesting issue that keeps coming up is incremental vs iterative . As Alistair Cockburn concisely puts it, Incremental means adding stuff, while
                              Message 15 of 21 , Mar 28, 2008
                                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@yahoogroups.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
                                >
                                >
                                >
                              • Tom Hume
                                Ah, we struggle with this one too. How do you ensure a consistent vision for a design across a broad product without doing a vast amount of up-front work and
                                Message 16 of 21 , Mar 28, 2008
                                  Ah, we struggle with this one too. How do you ensure a consistent
                                  vision for a design across a broad product without doing a vast amount
                                  of up-front work and coming over all waterfall?

                                  The approach you've recommended seems to involve stories delivering
                                  stuff that's valuable for the developers, not the customer (unless the
                                  customer is interested in reviewing interaction designs). That might
                                  not be too awful, but one of the things I've liked in our adoption of
                                  Scrum over the last 6 months is a focusing of the team around
                                  delivering things that matter to the customer, over and above
                                  performing activities.

                                  Ditto doing a period of up-front-design. I agonised about how we avoid
                                  doing this for a few weeks until I bumped into Jeff Patton at XP Day,
                                  who very nicely and sweetly told me not to be so silly and to do some
                                  up-front design if that's what's necessary.

                                  But we've still not cracked it, and talking to other folks there
                                  doesn't seem to be a recognised best-practice for this stuff.

                                  On 28 Mar 2008, at 10:35, mitchgrrt wrote:
                                  > 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
                                  >
                                  >
                                  >

                                  --
                                  Future Platforms Ltd
                                  e: Tom.Hume@...
                                  t: +44 (0) 1273 819038
                                  m: +44 (0) 7971 781422
                                  company: www.futureplatforms.com
                                  personal: tomhume.org
                                • Scott Preece
                                  Both - the *process* is iterative (you re cycling through the steps of figuring out, implementing, and validating), while the development itself is incremental
                                  Message 17 of 21 , Mar 28, 2008
                                    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
                                    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 18 of 21 , Mar 28, 2008

                                      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 19 of 21 , Mar 28, 2008
                                        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 20 of 21 , Mar 28, 2008

                                          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 21 of 21 , Mar 28, 2008

                                            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.