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

RE: [scrumdevelopment] Scrum with Distributed Team

Expand Messages
  • Wolfgang Schulze Zachau
    Aaarrrrgghhh. Product Owners out of state. Why the plural? Is there more than one of them? If there is more than one, it would be (much much) better to find a
    Message 1 of 11 , Oct 2, 2007
    • 0 Attachment
      Aaarrrrgghhh. Product Owners out of state. Why the plural? Is there more than one of them?
      If there is more than one, it would be (much much) better to find a PO who can be on site with the team and who can funnel their (probably contradicting) requests into ONE product backlog.
      Team on different site to the PM. Why? If there is enough space for the team, can the PM not fit in? What does the PM actually do? Is he the Scrum Master? I thought it was you? Or are you the government PM?
      Why are you recording actual hours? Scrum does not require this. Scrum (by the book) only requires estimation of hours remaining for incomplete tasks.
      I am going to be a heretic here: I found out that the estimation of remaining hours on open tasks was being abused by everybody and in the end we still had not completed all tasks, so I abolished this and now we only use three different states for each task: Initial, WIP, Done. Any task that was in WIP yesterday has to finish today, otherwise there is a problem (task to big, some impediment or someone slacking or some new discovery). KISS, all the way.
       
      Don't worry about the discovered tasks, that's normal, especially in your first couple of sprints. All it does is show that your team is being honest (which is good) and they are not afraid of reporting issues (also good). But do worry about your offsite product owners.
       

      Regards,

      Wolfgang

       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Huet Landry
      Sent: 02 October 2007 16:10
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Scrum with Distributed Team

      I serving as the ScrumMaster to roll out the Scum approach win a
      government organization. The organization has traditionally used a
      waterfall approach, but since our user requirements picture is in
      constant change, the management has been very supportive of this
      change.

      The team I am working with is facing several challenges which we are
      addressing, but I'd like some other opinions.

      Project Summary: Rehosting and redesign of a contractor-develope d
      web application to a government site. Delivery to Acceptance
      Testing at the end of December. Delivery to Production at end of
      February. (Yes, there is considerable organizational overhead.)

      Location: Government PM for the new system at one site, development
      team offsite (15 minute trip - due to space limitations) , product
      owners at a third site - out of state.

      Current practice: Weekly teleconferences (one day each week, plus
      another day every other week) with product owners to work on product
      backlog (use cases/scenarios. ) Daily Scrum with developers working
      on Sprint tasks. Weekly PM status meetings. First Sprint completed
      with successful demo.

      Issues from Sprint 1 Retrospective: Work on backlog lagging due to
      lack of time to work with the product owners. Difficulty in getting
      Sprint plan completed in a day - first one had several sets
      of "discovered" tasks added. Difficulty in embracing discipline of
      recording actual hours by task and recording task completion. Need
      to establish more frequent communication with product owners.

      Plans: Starting daily email summary of Scrum to product owners,
      with follow-up (by me). Videoconferencing with product owners has
      proved more effective than teleconference (duh) but we have limited
      access at present, though new equipment is being installed. Setting
      up product owner access to demo software. Plan for this Sprint is
      to require developers to report against named tasks in the daily
      Scrum to emphasize attention to the burndown chart.

      As Johnny Five would say "Input! Neeed More Input!"

      Huet Landry, PMP, CSM
      DHS (Unisys)

    • Hubert Smits
      Hi Huet, Let me give you some feedback below. --Hubert Huet Landry wrote: I serving as the ScrumMaster to roll out the Scum
      Message 2 of 11 , Oct 2, 2007
      • 0 Attachment
        Hi Huet,

        Let me give you some feedback below.

        --Hubert

        Huet Landry <huet.landry@...> wrote:
        I serving as the ScrumMaster to roll out the Scum approach win a
        government organization. The organization has traditionally used a
        waterfall approach, but since our user requirements picture is in
        constant change, the management has been very supportive of this
        change.

        Cool

        The team I am working with is facing several challenges which we are
        addressing, but I'd like some other opinions.
        Still cool

        Project Summary: Rehosting and redesign of a contractor-developed
        web application to a government site. Delivery to Acceptance
        Testing at the end of December. Delivery to Production at end of
        February. (Yes, there is considerable organizational overhead.)
        UAT not in the team: not cool, if you can get those people in the team you can save a lot of time, 20% or more.

        Location: Government PM for the new system at one site, development
        team offsite (15 minute trip - due to space limitations), product
        owners at a third site - out of state.
        You didn't mention team sizes, I assume that it is a single dev team, around 10 people. Where are the UAT folks located? I'm not sure what the role of the GOv. pm is, if there is a PO available then the PM feels like overhead. Not harmful or anything, just overhead.

        Current practice: Weekly teleconferences (one day each week, plus
        another day every other week) with product owners to work on product
        backlog (use cases/scenarios.) Daily Scrum with developers working
        on Sprint tasks. Weekly PM status meetings. First Sprint completed
        with successful demo.
        Congrats on the first Sprint, that is good news as it shows that all involved want to make it work.

        PO and backlog: how independent are those people? I know that they need to talk to the dev people to prepare stories, and to prepare for planning, but you shouldn't need to chase them weekly. Why are they writing design, and not just stories?

        Daily Scrum: good, are the UAT and PO people calling in?

        Weekly status meeting: not sure why you need this, it feels like overhead, but I can understand that a (government) organization requests this. The PM should get all info from the burndown and the stand-ups.

        Issues from Sprint 1 Retrospective: Work on backlog lagging due to
        lack of time to work with the product owners.
        Can you move this work into the sprint? Can the product owners be on-site for x days a week? Can you create a block of time every day or every other day to work with the PO, have you tried pairing tools like Google Docs?

        Difficulty in getting
        Sprint plan completed in a day - first one had several sets
        of "discovered" tasks added.
        No surprise for a first sprint planning, you will do better next time until you take only 3 - 4 hours. Are all people (team, PO, UAT, PM) in the room for the planning session, that saves a lot of time.

        Difficulty in embracing discipline of
        recording actual hours by task and recording task completion.
        Don't do actuals, or don't do them too precise. Only work with the required estimate to complete for every task. That should take less then a minute a day for the developers and testers.

        Need
        to establish more frequent communication with product owners.
        See above.
        Plans: Starting daily email summary of Scrum to product owners,
        with follow-up (by me).
        Why? You're creating work and they can attend the meeting. If they say they can't than they have not enough interest and won't read your reports either.
        Videoconferencing with product owners has
        proved more effective than teleconference (duh) but we have limited
        access at present, though new equipment is being installed.
        Go cheap with a webcam and messenger, works like a charm for quick meetings. Put the webcam on expenses as 'cheap lunch with customer' :-)
        Setting
        up product owner access to demo software.
        Should be easy with a good build process.
        Plan for this Sprint is
        to require developers to report against named tasks in the daily
        Scrum to emphasize attention to the burndown chart.
        Hmm, it may work but you're creating a status meeting, not a stand-up. Be very careful here, let the team self-organize (and the PO is part of the team).

        As Johnny Five would say "Input! Neeed More Input!"

        Huet Landry, PMP, CSM
        DHS (Unisys)





        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
        http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
        Individual Email | Traditional

        <*> To change settings online go to:
        http://groups.yahoo.com/group/scrumdevelopment/join
        (Yahoo! ID required)

        <*> To change settings via email:
        mailto:scrumdevelopment-digest@yahoogroups.com
        mailto:scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
        scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
        http://docs.yahoo.com/info/terms/


      • srinivas chillara
        ... I disagree. UAT is often a formal checkpoint, and a necessary step before s/w is taken up by user groups, or rolled out organisation wide. In case of
        Message 3 of 11 , Oct 3, 2007
        • 0 Attachment
          > UAT not in the team: not cool, if you can get those
          > people in the team you can save a lot of time, 20%
          > or more.

          I disagree. UAT is often a formal checkpoint, and a
          necessary step before s/w is taken up by user groups,
          or rolled out organisation wide.

          In case of complicated and large fuctionality being
          built the PO cannot be certain that software is "done"
          simply by spending time on the sprint review meeting.
          All he can make out is if the s/w is hopeless or not,
          and ofcourse if there are changes he/other users want
          based on what they can see.
          It might not be sufficient to decide if the number of
          bugs is at a tolerable level.
          UAT can be conducted under the supervision ofthe PO.


          However the team has to make the s/w sufficinetly good
          by thier own testing activities, and as such testers
          should be part of the team.

          Hopefully testers will learn some other skills and
          the others will learn some testing skills as sprints
          progress.

          cheers
          Cheenie








          Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html
        • Hubert Smits
          Hi Cheenie, Sorry to be unclear, UAT is absolutely necessary for the all the reasons you mention. It can be done as part of the Sprint though, and that saves
          Message 4 of 11 , Oct 3, 2007
          • 0 Attachment
            Hi Cheenie,

            Sorry to be unclear, UAT is absolutely necessary for the all the reasons you mention. It can be done as part of the Sprint though, and that saves lots of time because the Analysts can pair with the testers to write design and tests, then the developers can run the tests while they are coding, and finally the UAT folks can run the tests in a separate environment for final verification. This way the find bug / fix bug cycle becomes very short, unlike when the dev team has moved on to the next sprint and has to re-open the old code to fix bugs (which they had already modified because of the requirements in the new Sprint).

            Hope this helps,

            --Hubert

            srinivas chillara <ceezone@...> wrote:


            > UAT not in the team: not cool, if you can get those
            > people in the team you can save a lot of time, 20%
            > or more.

            I disagree. UAT is often a formal checkpoint, and a
            necessary step before s/w is taken up by user groups,
            or rolled out organisation wide.

            In case of complicated and large fuctionality being
            built the PO cannot be certain that software is "done"
            simply by spending time on the sprint review meeting.
            All he can make out is if the s/w is hopeless or not,
            and ofcourse if there are changes he/other users want
            based on what they can see.
            It might not be sufficient to decide if the number of
            bugs is at a tolerable level.
            UAT can be conducted under the supervision ofthe PO.


            However the team has to make the s/w sufficinetly good
            by thier own testing activities, and as such testers
            should be part of the team.

            Hopefully testers will learn some other skills and
            the others will learn some testing skills as sprints
            progress.

            cheers
            Cheenie








            Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html


            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links

            <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/scrumdevelopment/

            <*> Your email settings:
            Individual Email | Traditional

            <*> To change settings online go to:
            http://groups.yahoo.com/group/scrumdevelopment/join
            (Yahoo! ID required)

            <*> To change settings via email:
            mailto:scrumdevelopment-digest@yahoogroups.com
            mailto:scrumdevelopment-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
            scrumdevelopment-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
            http://docs.yahoo.com/info/terms/


          • srinivas chillara
            Hallo Hubert, ... By this if you mean the dev team running UAT tests (which have been made available) during the sprint that s OK and is a good idea.
            Message 5 of 11 , Oct 3, 2007
            • 0 Attachment
              Hallo Hubert,


              > Hi Cheenie,
              >
              > Sorry to be unclear, UAT is absolutely necessary for
              > the all the reasons you mention. It can be done as
              > part of the Sprint though,


              By this if you mean the dev team running UAT tests
              (which have been made available) during the sprint
              that's OK and is a good idea. Otherwise the activity
              of UAT itself cannot be run within the sprint, because
              the user or user groups are the only ones who can
              conduct the UAT (maybe under some guidance) and they
              are not part of the team.
              Also UAT must give confidence to the users (and the
              PO), so I'd suppose that the sponsors would wish that
              the UAT is done outside the sprint by non-dev-team
              members. (Here the dev-team can and should consist of
              testers)




              >and that saves lots of
              > time because the Analysts can pair with the testers
              > to write design and tests, then the developers can
              > run the tests while they are coding, and finally the
              > UAT folks can run the tests in a separate
              > environment for final verification.

              True, this is a good idea.


              cheers
              Cheenie




              Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php
            • Hubert Smits
              Hi Cheenie, Remember the art of the possible exercise from the CSM class? There is no reason why the majority of the UAT tests can t be run in the Sprint.
              Message 6 of 11 , Oct 3, 2007
              • 0 Attachment
                Hi Cheenie,

                Remember 'the art of the possible' exercise from the CSM class? There is no reason why the majority of the UAT tests can't be run in the Sprint. Issues with users and environments can easily be solved, if the team wants to solve them.

                --Hubert

                srinivas chillara <ceezone@...> wrote:

                Hallo Hubert,


                > Hi Cheenie,
                >
                > Sorry to be unclear, UAT is absolutely necessary for
                > the all the reasons you mention. It can be done as
                > part of the Sprint though,


                By this if you mean the dev team running UAT tests
                (which have been made available) during the sprint
                that's OK and is a good idea. Otherwise the activity
                of UAT itself cannot be run within the sprint, because
                the user or user groups are the only ones who can
                conduct the UAT (maybe under some guidance) and they
                are not part of the team.
                Also UAT must give confidence to the users (and the
                PO), so I'd suppose that the sponsors would wish that
                the UAT is done outside the sprint by non-dev-team
                members. (Here the dev-team can and should consist of
                testers)




                >and that saves lots of
                > time because the Analysts can pair with the testers
                > to write design and tests, then the developers can
                > run the tests while they are coding, and finally the
                > UAT folks can run the tests in a separate
                > environment for final verification.

                True, this is a good idea.


                cheers
                Cheenie




                Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php


                To Post a message, send it to: scrumdevelopment@...
                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                Yahoo! Groups Links

                <*> To visit your group on the web, go to:
                http://groups.yahoo.com/group/scrumdevelopment/

                <*> Your email settings:
                Individual Email | Traditional

                <*> To change settings online go to:
                http://groups.yahoo.com/group/scrumdevelopment/join
                (Yahoo! ID required)

                <*> To change settings via email:
                mailto:scrumdevelopment-digest@yahoogroups.com
                mailto:scrumdevelopment-fullfeatured@yahoogroups.com

                <*> To unsubscribe from this group, send an email to:
                scrumdevelopment-unsubscribe@yahoogroups.com

                <*> Your use of Yahoo! Groups is subject to:
                http://docs.yahoo.com/info/terms/


              • srinivas chillara
                Hello Hubert Smits This is a different way of looking at it, and I admit you are right. However (there is always a however) this is possible only after the
                Message 7 of 11 , Oct 3, 2007
                • 0 Attachment
                  Hello Hubert Smits

                  This is a different way of looking at it, and I admit
                  you are right. However (there is always a however)
                  this is possible only after the user groups and PO
                  already have a high level of confidence in the teams
                  ability to deliver the right software and of a high
                  quality.

                  So indeed it is possible. I havent seen this myself
                  personally.

                  cheers
                  Cheenie


                  > Hi Cheenie,
                  >
                  > Remember 'the art of the possible' exercise from the
                  > CSM class? There is no reason why the majority of
                  > the UAT tests can't be run in the Sprint. Issues
                  > with users and environments can easily be solved, if
                  > the team wants to solve them.
                  >
                  > --Hubert
                  >
                  > srinivas chillara <ceezone@...> wrote:
                  > Hallo Hubert,
                  >
                  >
                  > > Hi Cheenie,
                  > >
                  > > Sorry to be unclear, UAT is absolutely necessary
                  > for
                  > > the all the reasons you mention. It can be done as
                  > > part of the Sprint though,
                  >
                  >
                  > By this if you mean the dev team running UAT tests
                  > (which have been made available) during the sprint
                  > that's OK and is a good idea. Otherwise the activity
                  > of UAT itself cannot be run within the sprint,
                  > because
                  > the user or user groups are the only ones who can
                  > conduct the UAT (maybe under some guidance) and they
                  > are not part of the team.
                  > Also UAT must give confidence to the users (and the
                  > PO), so I'd suppose that the sponsors would wish
                  > that
                  > the UAT is done outside the sprint by non-dev-team
                  > members. (Here the dev-team can and should consist
                  > of
                  > testers)
                  >
                  >
                  >
                  >
                  > >and that saves lots of
                  > > time because the Analysts can pair with the
                  > testers
                  > > to write design and tests, then the developers can
                  > > run the tests while they are coding, and finally
                  > the
                  > > UAT folks can run the tests in a separate
                  > > environment for final verification.
                  >
                  > True, this is a good idea.
                  >
                  >
                  > cheers
                  > Cheenie
                  >
                  >
                  >
                  >
                  > Chat on a cool, new interface. No download
                  > required. Go to
                  > http://in.messenger.yahoo.com/webmessengerpromo.php
                  >
                  >
                  > To Post a message, send it to:
                  > scrumdevelopment@...
                  > To Unsubscribe, send a blank message to:
                  > scrumdevelopment-unsubscribe@...
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >



                  Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php
                • Huet Landry
                  Hubert (and others) Thanks for your comments and insight. ... Well, we re not chasing them weekly. Since they are both internal users and help desk support
                  Message 8 of 11 , Oct 12, 2007
                  • 0 Attachment
                    Hubert (and others)

                    Thanks for your comments and insight.

                    > PO and backlog: how independent are those people? I know that they
                    > need to talk to the dev people to prepare stories, and to prepare
                    > for planning, but you shouldn't need to chase them weekly. Why are
                    > they writing design, and not just stories?

                    Well, we're not 'chasing' them weekly. Since they are both internal
                    users and help desk support for external users, they have limited
                    time when the whole group can meet. They have committed to
                    answering email and phone questions within 24 hrs from developers.
                    They also have design/dev experience, since they also designed the
                    system we are porting. Our use cases are written at the system
                    level, with scenarios that detail system and user interactions.
                    Screen development is being done in parallel with the use cases.

                    >
                    > Daily Scrum: good, are the UAT and PO people calling in?

                    We're working on UAT folks calling in, but at present they are
                    writing tests from the use case scenarios. I'm having trouble
                    getting the PO folks convinced to call in daily, but they are also
                    commenting on the use cases regularly.

                    Due to the critical nature of some of our software and some poor
                    development practices in the past, our organization has two levels
                    of independant testing. This system also requires interface testing
                    with another major financial system and our PM is 'negotiating' a
                    timeframe with them (i.e. he's allowing them to test parallel with
                    the other two groups or - not at all.)

                    >
                    > Weekly status meeting: not sure why you need this, it feels like
                    overhead, but I can understand that a (government) organization
                    requests this. The PM should get all info from the burndown and the
                    stand-ups.

                    Due to the critical nature of some of our software and some poor
                    development practices in the past, our organization has two levels
                    of independant testing. This system also requires interface testing
                    with another major financial system and our PM is 'negotiating' a
                    timeframe with them (i.e. he's allowing them to test parallel with
                    the other two groups or - not at all.)

                    > Issues from Sprint 1 Retrospective: Work on backlog lagging due
                    to
                    > lack of time to work with the product owners.
                    > Can you move this work into the sprint? Can the product owners be
                    on-site for x days a week? Can you create a block of time every day
                    or every other day to work with the PO, have you tried pairing tools
                    like Google Docs?

                    That was what I was thinking, and we've done this with the second
                    sprint. We've also gotten some more interest from the local PO in
                    laying out a better backlog description.

                    >
                    > Difficulty in getting
                    > Sprint plan completed in a day - first one had several sets
                    > of "discovered" tasks added.
                    > No surprise for a first sprint planning, you will do better next
                    time until you take only 3 - 4 hours. Are all people (team, PO, UAT,
                    PM) in the room for the planning session, that saves a lot of time.

                    We have had good participation from all for at least the first 2 hrs
                    of planning.

                    >
                    > Difficulty in embracing discipline of
                    > recording actual hours by task and recording task completion.
                    > Don't do actuals, or don't do them too precise. Only work with the
                    required estimate to complete for every task. That should take less
                    then a minute a day for the developers and testers.

                    We've gone to the three-state (planned, in progreee, done) method,
                    and the oversight scheduler has agreed to allow this.

                    >
                    > Need
                    > to establish more frequent communication with product owners.
                    > See above.
                    > Plans: Starting daily email summary of Scrum to product owners,
                    > with follow-up (by me).
                    > Why? You're creating work and they can attend the meeting. If they
                    say they can't than they have not enough interest and won't read
                    your reports either.

                    Well, this is a busy organization, so most people have more than one
                    iron in the fire. The interest is there, but getting a time when
                    everyone's schedule is free is a miracle. We are seeing improvement
                    in their willingness to comment on use cases and attend the weekly
                    working sessions. The implemented functionality is updated daily on
                    a web server that all can access, so we're getting feedback from
                    that as well.

                    > Videoconferencing with product owners has
                    > proved more effective than teleconference (duh) but we have
                    limited
                    > access at present, though new equipment is being installed.
                    > Go cheap with a webcam and messenger, works like a charm for quick
                    meetings. Put the webcam on expenses as 'cheap lunch with
                    customer' :-)

                    Customer is footing the bill - they had some spare equipment in a
                    warehouse, so they just need to get the line connected.

                    > Plan for this Sprint is
                    > to require developers to report against named tasks in the daily
                    > Scrum to emphasize attention to the burndown chart.
                    > Hmm, it may work but you're creating a status meeting, not
                    > a stand-up. Be very careful here, let the team self-organize
                    > (and the PO is part of the team).

                    What I started doing was looking at the burndown before the scrum
                    and raising an issue if I saw few tasks completed from one day to
                    the next. So far, it's working well.

                    Huet
                  • Malcolm Anderson
                    I m not sure what you development environment is (Java - C# - Other), but I would highly recommend looking up a version of cruise control and having the
                    Message 9 of 11 , Oct 12, 2007
                    • 0 Attachment
                      I'm not sure what you development environment is (Java - C# - Other), but I would highly recommend looking up a version of cruise control and having the product built out and "deployed" to the UAT server EVERY time a successful check in happens.
                       
                      Continuous Integration is a VERY cool and useful thing.
                       
                      This way the users can actually see the current state of the product.  I think you will find that the feedback you get from this process will knock your socks off, not to mention surprising the PO.
                       
                      Malcolm
                      Agile Engineering Coach, CSP

                       
                      On 10/3/07, Hubert Smits <hubert.smits@...> wrote:

                      Hi Cheenie,

                      Sorry to be unclear, UAT is absolutely necessary for the all the reasons you mention. It can be done as part of the Sprint though, and that saves lots of time because the Analysts can pair with the testers to write design and tests, then the developers can run the tests while they are coding, and finally the UAT folks can run the tests in a separate environment for final verification. This way the find bug / fix bug cycle becomes very short, unlike when the dev team has moved on to the next sprint and has to re-open the old code to fix bugs (which they had already modified because of the requirements in the new Sprint).

                      Hope this helps,

                      --Hubert



                      srinivas chillara <ceezone@yahoo.co.in> wrote:


                      > UAT not in the team: not cool, if you can get those
                      > people in the team you can save a lot of time, 20%
                      > or more.

                      I disagree. UAT is often a formal checkpoint, and a
                      necessary step before s/w is taken up by user groups,
                      or rolled out organisation wide.

                      In case of complicated and large fuctionality being
                      built the PO cannot be certain that software is "done"
                      simply by spending time on the sprint review meeting.
                      All he can make out is if the s/w is hopeless or not,
                      and ofcourse if there are changes he/other users want
                      based on what they can see.
                      It might not be sufficient to decide if the number of
                      bugs is at a tolerable level.
                      UAT can be conducted under the supervision ofthe PO.


                      However the team has to make the s/w sufficinetly good
                      by thier own testing activities, and as such testers
                      should be part of the team.

                      Hopefully testers will learn some other skills and
                      the others will learn some testing skills as sprints
                      progress.

                      cheers
                      Cheenie








                      Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/ l/in/yahoo/mail/yahoomail/tools/tools-08.html


                      To Post a message, send it to: scrumdevelopment@...
                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                      Yahoo! Groups Links

                      <*> To visit your group on the web, go to:
                      http://groups.yahoo.com/group/scrumdevelopment/

                      <*> Your email settings:
                      Individual Email | Traditional

                      <*> To change settings online go to:
                      http://groups. yahoo.com/group/scrumdevelopment/join
                      (Yahoo! ID required)

                      <*> To change settings via email:
                      mailto: scrumdevelopment-digest@yahoogroups.com
                      mailto:scrumdevelop ment-fullfeatured@yahoogroups.com

                      <*> To unsubscribe from this group, send an email to:
                      scrumdevelopment-unsubscribe@yahoogroups.com

                      <*> Your use of Yahoo! Groups is subject to:
                      http://docs. yahoo.com/info/terms/



                    • David Milner
                      Totally agree. Also - incorporating unit tests (Junit, Nunit) into the CI builds really helps. And as the product comes along having regression scripts
                      Message 10 of 11 , Oct 12, 2007
                      • 0 Attachment
                        Totally agree.  Also - incorporating unit tests (Junit, Nunit) into the CI builds really helps.
                        And as the product comes along having regression scripts automated is great too, like fitnesse or fit,
                        or other tools like Mercury scripts.  Automate the old, granny test the new.
                         
                        Dave Milner

                        ----- Original Message ----
                        From: Malcolm Anderson <malcolm.b.anderson@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Friday, October 12, 2007 12:40:16 PM
                        Subject: Re: [scrumdevelopment] Scrum with Distributed Team

                        I'm not sure what you development environment is (Java - C# - Other), but I would highly recommend looking up a version of cruise control and having the product built out and "deployed" to the UAT server EVERY time a successful check in happens.
                         
                        Continuous Integration is a VERY cool and useful thing.
                         
                        This way the users can actually see the current state of the product.  I think you will find that the feedback you get from this process will knock your socks off, not to mention surprising the PO.
                         
                        Malcolm
                        Agile Engineering Coach, CSP

                         
                        On 10/3/07, Hubert Smits <hubert.smits@ btinternet. com> wrote:

                        Hi Cheenie,

                        Sorry to be unclear, UAT is absolutely necessary for the all the reasons you mention. It can be done as part of the Sprint though, and that saves lots of time because the Analysts can pair with the testers to write design and tests, then the developers can run the tests while they are coding, and finally the UAT folks can run the tests in a separate environment for final verification. This way the find bug / fix bug cycle becomes very short, unlike when the dev team has moved on to the next sprint and has to re-open the old code to fix bugs (which they had already modified because of the requirements in the new Sprint).

                        Hope this helps,

                        --Hubert



                        srinivas chillara <ceezone@yahoo.co.in> wrote:


                        > UAT not in the team: not cool, if you can get those
                        > people in the team you can save a lot of time, 20%
                        > or more.

                        I disagree. UAT is often a formal checkpoint, and a
                        necessary step before s/w is taken up by user groups,
                        or rolled out organisation wide.

                        In case of complicated and large fuctionality being
                        built the PO cannot be certain that software is "done"
                        simply by spending time on the sprint review meeting.
                        All he can make out is if the s/w is hopeless or not,
                        and ofcourse if there are changes he/other users want
                        based on what they can see.
                        It might not be sufficient to decide if the number of
                        bugs is at a tolerable level.
                        UAT can be conducted under the supervision ofthe PO.


                        However the team has to make the s/w sufficinetly good
                        by thier own testing activities, and as such testers
                        should be part of the team.

                        Hopefully testers will learn some other skills and
                        the others will learn some testing skills as sprints
                        progress.

                        cheers
                        Cheenie








                        Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/ l/in/yahoo/mail/ yahoomail/ tools/tools- 08.html


                        To Post a message, send it to: scrumdevelopment@ eGroups.com
                        To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.com
                        Yahoo! Groups Links

                        <*> To visit your group on the web, go to:
                        http://groups.yahoo.com/group/scrumdevelopm ent/

                        <*> Your email settings:
                        Individual Email | Traditional

                        <*> To change settings online go to:
                        http://groups. yahoo.com/group/scrumdevelopm ent/join
                        (Yahoo! ID required)

                        <*> To change settings via email:
                        mailto: scrumdevelopment-digest@ yahoogroups. com
                        mailto:scrumdevelop ment-fullfeatured@ yahoogroups. com

                        <*> To unsubscribe from this group, send an email to:
                        scrumdevelopment- unsubscribe@ yahoogroups. com

                        <*> Your use of Yahoo! Groups is subject to:
                        http://docs. yahoo.com/info/terms/






                        Be a better Globetrotter. Get better travel answers from someone who knows.
                        Yahoo! Answers - Check it out.
                      Your message has been successfully submitted and would be delivered to recipients shortly.