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

How to deal with specialist in the team

Expand Messages
  • jcarlos.moran
    Our product interacts with many other systems in the corporation e.g. SAP, middleware, DBA group, Corporate Architecture, data-warehouse, legacy billing
    Message 1 of 9 , Apr 25, 2011
      Our product interacts with many other systems in the corporation e.g. SAP, middleware, DBA group, Corporate Architecture, data-warehouse, legacy billing systems, etc.  Each system has it own team of specialist to support projects (new features) as well as day to day operations.  These resources are not dedicated resources in our team, and in most cases they are in a different location than the main team.

      Unlike the core team, not all specialist teams are affected by each story, so having them attend the whole planning session, does not seem to be the best use of their time (if they are not affected by most stories).

      • How do other companies deal with scheduling specialist time for planning a sprint or a release? 
      • How do they schedule their work in a time required by the core team?
        (reduce number of scheduling conflicts with other teams to complete the work)

      Thanks,

      Carlos Moran
    • avinap77
      Hi. In our shop we also run into similar situations. If the specialists are required only for occasional input, we regard them as an external resource at the
      Message 2 of 9 , Apr 25, 2011
        Hi.

        In our shop we also run into similar situations.

        If the specialists are required only for occasional input, we regard them as an external resource at the disposal of the team. That way the team is responsible for getting what they need from the specialists - including identifying the need, coordinating with the specialists etc.

        At some point this got out of hand and the team was relying too much on the specialists, so we budgeted it - for instace we allocate 4 hours of the specialists's time per sprint at the disposal of the team, so the team gets a sense of self-management managing their "budget". This also of course helps the specialists plan their time among their different projects.

        If the specialists need to create actual deliverables - for instance a graphics designer - we regard them as a seperate team, keeping a feeding buffer between dependent sprints (for instance in one sprint the graphics designer would create a GUI sketch and in the sprint afterward the developers would code it). This of course takes some overhead - having two daily standups, two planning meetings per sprint etc. one for each "team".

        I would also be interested in hearing of other's experience in these situations.

        HTH
        -Avi





        --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran" <jcarlos.moran@...> wrote:
        >
        > Our product interacts with many other systems in the corporation e.g.
        > SAP, middleware, DBA group, Corporate Architecture, data-warehouse,
        > legacy billing systems, etc. Each system has it own team of specialist
        > to support projects (new features) as well as day to day operations.
        > These resources are not dedicated resources in our team, and in most
        > cases they are in a different location than the main team.
        >
        > Unlike the core team, not all specialist teams are affected by each
        > story, so having them attend the whole planning session, does not seem
        > to be the best use of their time (if they are not affected by most
        > stories).
        >
        >
        > * How do other companies deal with scheduling specialist time for
        > planning a sprint or a release?
        >
        > * How do they schedule their work in a time required by the core
        > team?
        > (reduce number of scheduling conflicts with other teams to complete the
        > work)
        >
        > Thanks,
        >
        > Carlos Moran
        >
      • jcarlos.moran
        Avi, Thank you for your feedback. Your approach reminded me of how I did something similar at another company a few years ago (not related to Scrum or Agile,
        Message 3 of 9 , Apr 27, 2011
          Avi,

          Thank you for your feedback. Your approach reminded me of how I did
          something similar at another company a few years ago (not related to
          Scrum or Agile, but scheduling specialist). We used to have a standing
          one hour meeting every day. My team was responsible for managing the
          agenda i.e. bringing to the meeting a list of questions, and issues they
          needed answered to continue with their work/research. Whenever possible
          the list was sent to the specialist before hand, and if required
          follow-up meeting and action items were scheduled at the meeting. If
          there were no questions/issues in a particular day, the meeting was
          canceled and everyone gained an extra hour in the day. This approach as
          you mentioned helped the specialist schedule and budget their time
          better.

          Now, regarding splitting the work in two sprints for dependencies, Do
          you create to user stories (or PBIs) and assigned them to two separate
          sprints? or just did not marked the story as done and moved it to the
          next sprint and assigned the tasks to the second team?

          Thanks,

          Carlos

          --- In scrumdevelopment@yahoogroups.com, "avinap77" <avi_a@...> wrote:
          >
          > Hi.
          >
          > In our shop we also run into similar situations.
          >
          > If the specialists are required only for occasional input, we regard
          them as an external resource at the disposal of the team. That way the
          team is responsible for getting what they need from the specialists -
          including identifying the need, coordinating with the specialists etc.
          >
          > At some point this got out of hand and the team was relying too much
          on the specialists, so we budgeted it - for instace we allocate 4 hours
          of the specialists's time per sprint at the disposal of the team, so the
          team gets a sense of self-management managing their "budget". This also
          of course helps the specialists plan their time among their different
          projects.
          >
          > If the specialists need to create actual deliverables - for instance a
          graphics designer - we regard them as a seperate team, keeping a feeding
          buffer between dependent sprints (for instance in one sprint the
          graphics designer would create a GUI sketch and in the sprint afterward
          the developers would code it). This of course takes some overhead -
          having two daily standups, two planning meetings per sprint etc. one for
          each "team".
          >
          > I would also be interested in hearing of other's experience in these
          situations.
          >
          > HTH
          > -Avi
          >
          >
          >
          >
          >
          > --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran"
          jcarlos.moran@ wrote:
          > >
          > > Our product interacts with many other systems in the corporation
          e.g.
          > > SAP, middleware, DBA group, Corporate Architecture, data-warehouse,
          > > legacy billing systems, etc. Each system has it own team of
          specialist
          > > to support projects (new features) as well as day to day operations.
          > > These resources are not dedicated resources in our team, and in most
          > > cases they are in a different location than the main team.
          > >
          > > Unlike the core team, not all specialist teams are affected by each
          > > story, so having them attend the whole planning session, does not
          seem
          > > to be the best use of their time (if they are not affected by most
          > > stories).
          > >
          > >
          > > * How do other companies deal with scheduling specialist time
          for
          > > planning a sprint or a release?
          > >
          > > * How do they schedule their work in a time required by the core
          > > team?
          > > (reduce number of scheduling conflicts with other teams to complete
          the
          > > work)
          > >
          > > Thanks,
          > >
          > > Carlos Moran
          > >
          >
        • Andrew Pham
          Hi Avi and Carlos, How did you both do your estimate in this case? Did you use planning poker? How did it work? Andrew Agile and Lean Coach, Author of *Scrum
          Message 4 of 9 , Apr 27, 2011
            Hi Avi and Carlos,
            How did you both do your estimate in this case? Did you use planning poker? How did it work?
            Andrew



            On Tue, Apr 26, 2011 at 1:53 AM, avinap77 <avi_a@...> wrote:
             

            Hi.

            In our shop we also run into similar situations.

            If the specialists are required only for occasional input, we regard them as an external resource at the disposal of the team. That way the team is responsible for getting what they need from the specialists - including identifying the need, coordinating with the specialists etc.

            At some point this got out of hand and the team was relying too much on the specialists, so we budgeted it - for instace we allocate 4 hours of the specialists's time per sprint at the disposal of the team, so the team gets a sense of self-management managing their "budget". This also of course helps the specialists plan their time among their different projects.

            If the specialists need to create actual deliverables - for instance a graphics designer - we regard them as a seperate team, keeping a feeding buffer between dependent sprints (for instance in one sprint the graphics designer would create a GUI sketch and in the sprint afterward the developers would code it). This of course takes some overhead - having two daily standups, two planning meetings per sprint etc. one for each "team".

            I would also be interested in hearing of other's experience in these situations.

            HTH
            -Avi



            --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran" <jcarlos.moran@...> wrote:
            >
            > Our product interacts with many other systems in the corporation e.g.
            > SAP, middleware, DBA group, Corporate Architecture, data-warehouse,
            > legacy billing systems, etc. Each system has it own team of specialist
            > to support projects (new features) as well as day to day operations.
            > These resources are not dedicated resources in our team, and in most
            > cases they are in a different location than the main team.
            >
            > Unlike the core team, not all specialist teams are affected by each
            > story, so having them attend the whole planning session, does not seem
            > to be the best use of their time (if they are not affected by most
            > stories).
            >
            >
            > * How do other companies deal with scheduling specialist time for
            > planning a sprint or a release?
            >
            > * How do they schedule their work in a time required by the core
            > team?
            > (reduce number of scheduling conflicts with other teams to complete the
            > work)
            >
            > Thanks,
            >
            > Carlos Moran
            >


          • avinap77
            Hi Carlos. When splitting work across two (or more) teams I prefer to make 2 PBI s - one for each team. Sometimes this will be two copies of the same PBI
            Message 5 of 9 , Apr 28, 2011
              Hi Carlos.

              When splitting work across two (or more) teams I prefer to make 2 PBI's - one for each team.

              Sometimes this will be two "copies" of the same PBI split across technical boundries (for inatance - a PBI that deals with a search screen might be split into one PBI for the graphics team and another PBI for the dev team)

              and sometimes I'll just split out a PBI as a task from the original PBI - for instance from the story of the search screen I'll split a seperate PBI just saying "make graphics sketches" for the graphics team and keep the original PBI for the dev-team, knowing they need the sketches in order to begin working.

              When doing this I need to of course take into consideration each PBI's estimates - for instance I won't enter a story point estimate for a split-out task since it doesn't count as extra value-points or the customer, but I might give it a "private" estimate to track the progress of the secondary team.

              Either way I wouldn't have the same PBI "move" between teams - it's easiest to have each PBI either DONE or NOT DONE - having a PBI "HALF DONE" or "IN TRANSITION" is hard to track at the release-level.

              FWIW the idea of splitting work between teams is covered quite nicely in Mike Cohn's "Agile Estimating and Planning" book (Chapter 18 - "Planning the multiple-team project") - I definitely recommend reading it if you haven't yet.

              Best wishes,
              - Avi




              --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran" <jcarlos.moran@...> wrote:
              >
              > Avi,
              >
              > Thank you for your feedback. Your approach reminded me of how I did
              > something similar at another company a few years ago (not related to
              > Scrum or Agile, but scheduling specialist). We used to have a standing
              > one hour meeting every day. My team was responsible for managing the
              > agenda i.e. bringing to the meeting a list of questions, and issues they
              > needed answered to continue with their work/research. Whenever possible
              > the list was sent to the specialist before hand, and if required
              > follow-up meeting and action items were scheduled at the meeting. If
              > there were no questions/issues in a particular day, the meeting was
              > canceled and everyone gained an extra hour in the day. This approach as
              > you mentioned helped the specialist schedule and budget their time
              > better.
              >
              > Now, regarding splitting the work in two sprints for dependencies, Do
              > you create to user stories (or PBIs) and assigned them to two separate
              > sprints? or just did not marked the story as done and moved it to the
              > next sprint and assigned the tasks to the second team?
              >
              > Thanks,
              >
              > Carlos
              >
              > --- In scrumdevelopment@yahoogroups.com, "avinap77" <avi_a@> wrote:
              > >
              > > Hi.
              > >
              > > In our shop we also run into similar situations.
              > >
              > > If the specialists are required only for occasional input, we regard
              > them as an external resource at the disposal of the team. That way the
              > team is responsible for getting what they need from the specialists -
              > including identifying the need, coordinating with the specialists etc.
              > >
              > > At some point this got out of hand and the team was relying too much
              > on the specialists, so we budgeted it - for instace we allocate 4 hours
              > of the specialists's time per sprint at the disposal of the team, so the
              > team gets a sense of self-management managing their "budget". This also
              > of course helps the specialists plan their time among their different
              > projects.
              > >
              > > If the specialists need to create actual deliverables - for instance a
              > graphics designer - we regard them as a seperate team, keeping a feeding
              > buffer between dependent sprints (for instance in one sprint the
              > graphics designer would create a GUI sketch and in the sprint afterward
              > the developers would code it). This of course takes some overhead -
              > having two daily standups, two planning meetings per sprint etc. one for
              > each "team".
              > >
              > > I would also be interested in hearing of other's experience in these
              > situations.
              > >
              > > HTH
              > > -Avi
              > >
              > >
              > >
              > >
              > >
              > > --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran"
              > jcarlos.moran@ wrote:
              > > >
              > > > Our product interacts with many other systems in the corporation
              > e.g.
              > > > SAP, middleware, DBA group, Corporate Architecture, data-warehouse,
              > > > legacy billing systems, etc. Each system has it own team of
              > specialist
              > > > to support projects (new features) as well as day to day operations.
              > > > These resources are not dedicated resources in our team, and in most
              > > > cases they are in a different location than the main team.
              > > >
              > > > Unlike the core team, not all specialist teams are affected by each
              > > > story, so having them attend the whole planning session, does not
              > seem
              > > > to be the best use of their time (if they are not affected by most
              > > > stories).
              > > >
              > > >
              > > > * How do other companies deal with scheduling specialist time
              > for
              > > > planning a sprint or a release?
              > > >
              > > > * How do they schedule their work in a time required by the core
              > > > team?
              > > > (reduce number of scheduling conflicts with other teams to complete
              > the
              > > > work)
              > > >
              > > > Thanks,
              > > >
              > > > Carlos Moran
              > > >
              > >
              >
            • jcarlos.moran
              Avi, Thank you for your help. I did read Mike s book, but it was in 2007, and I did not have to deal with this issue until now, so I will go back and read the
              Message 6 of 9 , Apr 29, 2011
                Avi,

                Thank you for your help. I did read Mike's book, but it was in 2007, and I did not have to deal with this issue until now, so I will go back and read the chapter you recommended.

                Thanks again!

                Carlos

                --- In scrumdevelopment@yahoogroups.com, "avinap77" <avi_a@...> wrote:
                >
                > Hi Carlos.
                >
                > When splitting work across two (or more) teams I prefer to make 2 PBI's - one for each team.
                >
                > Sometimes this will be two "copies" of the same PBI split across technical boundries (for inatance - a PBI that deals with a search screen might be split into one PBI for the graphics team and another PBI for the dev team)
                >
                > and sometimes I'll just split out a PBI as a task from the original PBI - for instance from the story of the search screen I'll split a seperate PBI just saying "make graphics sketches" for the graphics team and keep the original PBI for the dev-team, knowing they need the sketches in order to begin working.
                >
                > When doing this I need to of course take into consideration each PBI's estimates - for instance I won't enter a story point estimate for a split-out task since it doesn't count as extra value-points or the customer, but I might give it a "private" estimate to track the progress of the secondary team.
                >
                > Either way I wouldn't have the same PBI "move" between teams - it's easiest to have each PBI either DONE or NOT DONE - having a PBI "HALF DONE" or "IN TRANSITION" is hard to track at the release-level.
                >
                > FWIW the idea of splitting work between teams is covered quite nicely in Mike Cohn's "Agile Estimating and Planning" book (Chapter 18 - "Planning the multiple-team project") - I definitely recommend reading it if you haven't yet.
                >
                > Best wishes,
                > - Avi
                >
                >
                >
                >
                > --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran" <jcarlos.moran@> wrote:
                > >
                > > Avi,
                > >
                > > Thank you for your feedback. Your approach reminded me of how I did
                > > something similar at another company a few years ago (not related to
                > > Scrum or Agile, but scheduling specialist). We used to have a standing
                > > one hour meeting every day. My team was responsible for managing the
                > > agenda i.e. bringing to the meeting a list of questions, and issues they
                > > needed answered to continue with their work/research. Whenever possible
                > > the list was sent to the specialist before hand, and if required
                > > follow-up meeting and action items were scheduled at the meeting. If
                > > there were no questions/issues in a particular day, the meeting was
                > > canceled and everyone gained an extra hour in the day. This approach as
                > > you mentioned helped the specialist schedule and budget their time
                > > better.
                > >
                > > Now, regarding splitting the work in two sprints for dependencies, Do
                > > you create to user stories (or PBIs) and assigned them to two separate
                > > sprints? or just did not marked the story as done and moved it to the
                > > next sprint and assigned the tasks to the second team?
                > >
                > > Thanks,
                > >
                > > Carlos
                > >
                > > --- In scrumdevelopment@yahoogroups.com, "avinap77" <avi_a@> wrote:
                > > >
                > > > Hi.
                > > >
                > > > In our shop we also run into similar situations.
                > > >
                > > > If the specialists are required only for occasional input, we regard
                > > them as an external resource at the disposal of the team. That way the
                > > team is responsible for getting what they need from the specialists -
                > > including identifying the need, coordinating with the specialists etc.
                > > >
                > > > At some point this got out of hand and the team was relying too much
                > > on the specialists, so we budgeted it - for instace we allocate 4 hours
                > > of the specialists's time per sprint at the disposal of the team, so the
                > > team gets a sense of self-management managing their "budget". This also
                > > of course helps the specialists plan their time among their different
                > > projects.
                > > >
                > > > If the specialists need to create actual deliverables - for instance a
                > > graphics designer - we regard them as a seperate team, keeping a feeding
                > > buffer between dependent sprints (for instance in one sprint the
                > > graphics designer would create a GUI sketch and in the sprint afterward
                > > the developers would code it). This of course takes some overhead -
                > > having two daily standups, two planning meetings per sprint etc. one for
                > > each "team".
                > > >
                > > > I would also be interested in hearing of other's experience in these
                > > situations.
                > > >
                > > > HTH
                > > > -Avi
                > > >
                > > >
                > > >
                > > >
                > > >
                > > > --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran"
                > > jcarlos.moran@ wrote:
                > > > >
                > > > > Our product interacts with many other systems in the corporation
                > > e.g.
                > > > > SAP, middleware, DBA group, Corporate Architecture, data-warehouse,
                > > > > legacy billing systems, etc. Each system has it own team of
                > > specialist
                > > > > to support projects (new features) as well as day to day operations.
                > > > > These resources are not dedicated resources in our team, and in most
                > > > > cases they are in a different location than the main team.
                > > > >
                > > > > Unlike the core team, not all specialist teams are affected by each
                > > > > story, so having them attend the whole planning session, does not
                > > seem
                > > > > to be the best use of their time (if they are not affected by most
                > > > > stories).
                > > > >
                > > > >
                > > > > * How do other companies deal with scheduling specialist time
                > > for
                > > > > planning a sprint or a release?
                > > > >
                > > > > * How do they schedule their work in a time required by the core
                > > > > team?
                > > > > (reduce number of scheduling conflicts with other teams to complete
                > > the
                > > > > work)
                > > > >
                > > > > Thanks,
                > > > >
                > > > > Carlos Moran
                > > > >
                > > >
                > >
                >
              • avi_a@mapa.co.il
                Hi Andrew. I did not use planning poker or any special estimating techniques in these situations - I just had each team estimate it s own work. (I say team
                Message 7 of 9 , Apr 30, 2011
                  Hi Andrew.

                  I did not use planning poker or any special estimating techniques in these situations - I just had each "team" estimate it's own work.

                  (I say "team" since the specialists were working solo but for planning and scheduling purposes I regarded them as a separate team).

                  All in all it seemed to work OK - the important aspect for me was to handle the dependencies between the "teams" - so for this matter using separate PBI's and keeping them in separate sprints (a-la- feeding buffer and lookahead planning) was enough.

                  Sometimes I didn't even bother estimating the tasks of the "secondary" specialist team - since the specialist wasn't into the "scrum spirit" and we just needed to make sure we got what we needed from him/her in a schedule that would allow the main scrum-team to proceed with what they needed.

                  I suppose if there were two real teams working throughout the entire release it would make sense to use some kind of collaborative cross-team technique, but admittedly I haven't run into the need yet....

                  - Avi


                  --- In scrumdevelopment@yahoogroups.com, Andrew Pham <andrewpham74@...> wrote:
                  >
                  > Hi Avi and Carlos,
                  > How did you both do your estimate in this case? Did you use planning poker?
                  > How did it work?
                  > Andrew
                  > Agile and Lean Coach, Author of *Scrum in Action*
                  > http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_
                  > *1*<http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1>
                  > *-1
                  > *
                  > *<https://sites.google.com/a/agileenterpriseconsulting.com/agile-enterprise-consulting/home>
                  > *
                  >
                  >
                  > On Tue, Apr 26, 2011 at 1:53 AM, avinap77 <avi_a@...> wrote:
                  >
                  > >
                  > >
                  > > Hi.
                  > >
                  > > In our shop we also run into similar situations.
                  > >
                  > > If the specialists are required only for occasional input, we regard them
                  > > as an external resource at the disposal of the team. That way the team is
                  > > responsible for getting what they need from the specialists - including
                  > > identifying the need, coordinating with the specialists etc.
                  > >
                  > > At some point this got out of hand and the team was relying too much on the
                  > > specialists, so we budgeted it - for instace we allocate 4 hours of the
                  > > specialists's time per sprint at the disposal of the team, so the team gets
                  > > a sense of self-management managing their "budget". This also of course
                  > > helps the specialists plan their time among their different projects.
                  > >
                  > > If the specialists need to create actual deliverables - for instance a
                  > > graphics designer - we regard them as a seperate team, keeping a feeding
                  > > buffer between dependent sprints (for instance in one sprint the graphics
                  > > designer would create a GUI sketch and in the sprint afterward the
                  > > developers would code it). This of course takes some overhead - having two
                  > > daily standups, two planning meetings per sprint etc. one for each "team".
                  > >
                  > > I would also be interested in hearing of other's experience in these
                  > > situations.
                  > >
                  > > HTH
                  > > -Avi
                  > >
                  > >
                  > > --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran" <jcarlos.moran@>
                  > > wrote:
                  > > >
                  > > > Our product interacts with many other systems in the corporation e.g.
                  > > > SAP, middleware, DBA group, Corporate Architecture, data-warehouse,
                  > > > legacy billing systems, etc. Each system has it own team of specialist
                  > > > to support projects (new features) as well as day to day operations.
                  > > > These resources are not dedicated resources in our team, and in most
                  > > > cases they are in a different location than the main team.
                  > > >
                  > > > Unlike the core team, not all specialist teams are affected by each
                  > > > story, so having them attend the whole planning session, does not seem
                  > > > to be the best use of their time (if they are not affected by most
                  > > > stories).
                  > > >
                  > > >
                  > > > * How do other companies deal with scheduling specialist time for
                  > > > planning a sprint or a release?
                  > > >
                  > > > * How do they schedule their work in a time required by the core
                  > > > team?
                  > > > (reduce number of scheduling conflicts with other teams to complete the
                  > > > work)
                  > > >
                  > > > Thanks,
                  > > >
                  > > > Carlos Moran
                  > > >
                  > >
                  > >
                  > >
                  >
                • Andrew Pham
                  ... It looks like the root cause of this kind of problems (with how to split PBIs) came from the fact that the user stories were not consistently written at
                  Message 8 of 9 , Apr 30, 2011
                    On Thu, Apr 28, 2011 at 7:15 AM, avinap77 <avi_a@...> wrote:
                     

                    Hi Carlos.

                    When splitting work across two (or more) teams I prefer to make 2 PBI's - one for each team.

                    Sometimes this will be two "copies" of the same PBI split across technical boundries (for inatance - a PBI that deals with a search screen might be split into one PBI for the graphics team and another PBI for the dev team)

                    and sometimes I'll just split out a PBI as a task from the original PBI - for instance from the story of the search screen I'll split a seperate PBI just saying "make graphics sketches" for the graphics team and keep the original PBI for the dev-team, knowing they need the sketches in order to begin working.


                    It looks like the root cause of this kind of problems (with how to split PBIs) came from the fact that the user stories were not consistently written at the same level of detail. It is not anyone's fault, it is rather difficult in the trenches despite the fact that everything sounds rather simple and easy (but only deceptively) in Agile or Scrum, especially when it comes to user stories writing...

                    One simple technique I use, from the day I was still a director of software development until now as a coach, that has proven to help a lot of Agile and Scrum teams come up with user stories at the same consistent level of detail is called "the Tree and the Forest" (chapter 4 in my Scrum book).

                    What it does is to walk the teams progressively through a systematic top down decomposition process going from the overall product (the forest), to the trees (sub-product), then to the branches (components) and to the leaves (the actual user stories).

                    Best,
                    Andrew
                     


                    When doing this I need to of course take into consideration each PBI's estimates - for instance I won't enter a story point estimate for a split-out task since it doesn't count as extra value-points or the customer, but I might give it a "private" estimate to track the progress of the secondary team.

                    Either way I wouldn't have the same PBI "move" between teams - it's easiest to have each PBI either DONE or NOT DONE - having a PBI "HALF DONE" or "IN TRANSITION" is hard to track at the release-level.

                    FWIW the idea of splitting work between teams is covered quite nicely in Mike Cohn's "Agile Estimating and Planning" book (Chapter 18 - "Planning the multiple-team project") - I definitely recommend reading it if you haven't yet.

                    Best wishes,
                    - Avi



                    --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran" <jcarlos.moran@...> wrote:
                    >
                    > Avi,
                    >
                    > Thank you for your feedback. Your approach reminded me of how I did
                    > something similar at another company a few years ago (not related to
                    > Scrum or Agile, but scheduling specialist). We used to have a standing
                    > one hour meeting every day. My team was responsible for managing the
                    > agenda i.e. bringing to the meeting a list of questions, and issues they
                    > needed answered to continue with their work/research. Whenever possible
                    > the list was sent to the specialist before hand, and if required
                    > follow-up meeting and action items were scheduled at the meeting. If
                    > there were no questions/issues in a particular day, the meeting was
                    > canceled and everyone gained an extra hour in the day. This approach as
                    > you mentioned helped the specialist schedule and budget their time
                    > better.
                    >
                    > Now, regarding splitting the work in two sprints for dependencies, Do
                    > you create to user stories (or PBIs) and assigned them to two separate
                    > sprints? or just did not marked the story as done and moved it to the
                    > next sprint and assigned the tasks to the second team?
                    >
                    > Thanks,
                    >
                    > Carlos
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "avinap77" <avi_a@> wrote:
                    > >
                    > > Hi.
                    > >
                    > > In our shop we also run into similar situations.
                    > >
                    > > If the specialists are required only for occasional input, we regard
                    > them as an external resource at the disposal of the team. That way the
                    > team is responsible for getting what they need from the specialists -
                    > including identifying the need, coordinating with the specialists etc.
                    > >
                    > > At some point this got out of hand and the team was relying too much
                    > on the specialists, so we budgeted it - for instace we allocate 4 hours
                    > of the specialists's time per sprint at the disposal of the team, so the
                    > team gets a sense of self-management managing their "budget". This also
                    > of course helps the specialists plan their time among their different
                    > projects.
                    > >
                    > > If the specialists need to create actual deliverables - for instance a
                    > graphics designer - we regard them as a seperate team, keeping a feeding
                    > buffer between dependent sprints (for instance in one sprint the
                    > graphics designer would create a GUI sketch and in the sprint afterward
                    > the developers would code it). This of course takes some overhead -
                    > having two daily standups, two planning meetings per sprint etc. one for
                    > each "team".
                    > >
                    > > I would also be interested in hearing of other's experience in these
                    > situations.
                    > >
                    > > HTH
                    > > -Avi
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran"
                    > jcarlos.moran@ wrote:
                    > > >
                    > > > Our product interacts with many other systems in the corporation
                    > e.g.
                    > > > SAP, middleware, DBA group, Corporate Architecture, data-warehouse,
                    > > > legacy billing systems, etc. Each system has it own team of
                    > specialist
                    > > > to support projects (new features) as well as day to day operations.
                    > > > These resources are not dedicated resources in our team, and in most
                    > > > cases they are in a different location than the main team.
                    > > >
                    > > > Unlike the core team, not all specialist teams are affected by each
                    > > > story, so having them attend the whole planning session, does not
                    > seem
                    > > > to be the best use of their time (if they are not affected by most
                    > > > stories).
                    > > >
                    > > >
                    > > > * How do other companies deal with scheduling specialist time
                    > for
                    > > > planning a sprint or a release?
                    > > >
                    > > > * How do they schedule their work in a time required by the core
                    > > > team?
                    > > > (reduce number of scheduling conflicts with other teams to complete
                    > the
                    > > > work)
                    > > >
                    > > > Thanks,
                    > > >
                    > > > Carlos Moran
                    > > >
                    > >
                    >


                  • Andrew Pham
                    ... Hi Avi, Thank you for the answer which does not surprise me as it is also in line with what I do.... All the best, Andrew Pham Agile and Lean Coach, author
                    Message 9 of 9 , Apr 30, 2011
                      On Sat, Apr 30, 2011 at 2:42 AM, <avi_a@...> wrote:
                       

                      Hi Andrew.

                      I did not use planning poker or any special estimating techniques in these situations - I just had each "team" estimate it's own work.

                       
                      Hi Avi,

                      Thank you for the answer which does not surprise me as it is also in line with what I do....

                      All the best,

                      Andrew Pham
                      Agile and Lean Coach, author of Scrum in Action
                      http://www.agileenterpriseconsulting.com/training (1-day online Scrum training)


                      (I say "team" since the specialists were working solo but for planning and scheduling purposes I regarded them as a separate team).

                      All in all it seemed to work OK - the important aspect for me was to handle the dependencies between the "teams" - so for this matter using separate PBI's and keeping them in separate sprints (a-la- feeding buffer and lookahead planning) was enough.

                      Sometimes I didn't even bother estimating the tasks of the "secondary" specialist team - since the specialist wasn't into the "scrum spirit" and we just needed to make sure we got what we needed from him/her in a schedule that would allow the main scrum-team to proceed with what they needed.

                      I suppose if there were two real teams working throughout the entire release it would make sense to use some kind of collaborative cross-team technique, but admittedly I haven't run into the need yet....

                      - Avi



                      --- In scrumdevelopment@yahoogroups.com, Andrew Pham <andrewpham74@...> wrote:
                      >
                      > Hi Avi and Carlos,
                      > How did you both do your estimate in this case? Did you use planning poker?
                      > How did it work?
                      > Andrew
                      > Agile and Lean Coach, Author of *Scrum in Action*
                      > http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_
                      > *1*<http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1>
                      > *-1
                      > *
                      > *<https://sites.google.com/a/agileenterpriseconsulting.com/agile-enterprise-consulting/home>
                      > *

                      >
                      >
                      > On Tue, Apr 26, 2011 at 1:53 AM, avinap77 <avi_a@...> wrote:
                      >
                      > >
                      > >
                      > > Hi.
                      > >
                      > > In our shop we also run into similar situations.
                      > >
                      > > If the specialists are required only for occasional input, we regard them
                      > > as an external resource at the disposal of the team. That way the team is
                      > > responsible for getting what they need from the specialists - including
                      > > identifying the need, coordinating with the specialists etc.
                      > >
                      > > At some point this got out of hand and the team was relying too much on the
                      > > specialists, so we budgeted it - for instace we allocate 4 hours of the
                      > > specialists's time per sprint at the disposal of the team, so the team gets
                      > > a sense of self-management managing their "budget". This also of course
                      > > helps the specialists plan their time among their different projects.
                      > >
                      > > If the specialists need to create actual deliverables - for instance a
                      > > graphics designer - we regard them as a seperate team, keeping a feeding
                      > > buffer between dependent sprints (for instance in one sprint the graphics
                      > > designer would create a GUI sketch and in the sprint afterward the
                      > > developers would code it). This of course takes some overhead - having two
                      > > daily standups, two planning meetings per sprint etc. one for each "team".
                      > >
                      > > I would also be interested in hearing of other's experience in these
                      > > situations.
                      > >
                      > > HTH
                      > > -Avi
                      > >
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com, "jcarlos.moran" <jcarlos.moran@>
                      > > wrote:
                      > > >
                      > > > Our product interacts with many other systems in the corporation e.g.
                      > > > SAP, middleware, DBA group, Corporate Architecture, data-warehouse,
                      > > > legacy billing systems, etc. Each system has it own team of specialist
                      > > > to support projects (new features) as well as day to day operations.
                      > > > These resources are not dedicated resources in our team, and in most
                      > > > cases they are in a different location than the main team.
                      > > >
                      > > > Unlike the core team, not all specialist teams are affected by each
                      > > > story, so having them attend the whole planning session, does not seem
                      > > > to be the best use of their time (if they are not affected by most
                      > > > stories).
                      > > >
                      > > >
                      > > > * How do other companies deal with scheduling specialist time for
                      > > > planning a sprint or a release?
                      > > >
                      > > > * How do they schedule their work in a time required by the core
                      > > > team?
                      > > > (reduce number of scheduling conflicts with other teams to complete the
                      > > > work)
                      > > >
                      > > > Thanks,
                      > > >
                      > > > Carlos Moran
                      > > >
                      > >
                      > >
                      > >
                      >


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