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

Re: [scrumdevelopment] Concept of "work ahead" team

Expand Messages
  • Madhur Kathuria
    Hey Richard IMHO, Well the look ahead teams ( I call them planning teams) exist in organizations because of the basic SDLC and because of planning pressures (
    Message 1 of 25 , Aug 27, 2013
    • 0 Attachment
      Hey Richard

      IMHO, Well the look ahead teams ( I call them planning teams) exist in organizations because of the basic SDLC and because of planning pressures ( or lack of them there of)

      In an ideal world, teams would not only focus on current work but also look into the future and plan for what they need to do in next couple of Sprints but in most orgs, the team gets so drowned in the current work that they forget to look into future and the results are mid sprint surprises, half baked stories, Non existent Done criterion et al

      Yes, with better planning of capacity and in-sprint calendar and with a bit of vision, the team should be able to manage all things but till the time that happens, the Planning team(s) will continue to exist

      on the flip side, with some of my clients, I have seen the planning teams being the tech champions and they provide the direction and vision for product research and development because of their experience and deeper understanding of the product/domain/technology

      To summarize, the Planning teams may not be evil ( even useful) but there can also be better, collaborative ways to plan the future :)


      ---
      With Regards,
      Madhur Kathuria, CSC, CSP, CSM, CSA
      Chair, India Scrum Enthusiasts Community (ISEC)
      Founder, Agile Pune
       
      Call: +91.8506011150
      Skype: madhur.kathuria


      On 27 August 2013 12:28, Richard Griffiths <richard@...> wrote:
       

      Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

       

      Shouldn’t the whole team be involved in these exercises, not the chosen few?

       

      --

      Richard

       

      Speed is n0 subsitute fnor accurancy

       


    • Michael James
      Yeah, manager-assigned roles don t strike me as consistent with the spirit of team self organization. When you refer to the chosen few I m curious who is
      Message 2 of 25 , Aug 27, 2013
      • 0 Attachment
        Yeah, manager-assigned roles don't strike me as consistent with the spirit of team self organization.  When you refer to the "chosen few" I'm curious who is doing that choosing.

        In theory the whole team should be allowed to reject or revise the tentative decisions of its subcommittee, but in practice I've seen a kind of momentum preventing this.

        I'd want the Product Owner involved too.

        --mj
        (Michael)


        On Aug 26, 2013, at 11:58 PM, "Richard Griffiths" <richard@...> wrote:

         

        Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

         

        Shouldn’t the whole team be involved in these exercises, not the chosen few?

         

        --

        Richard

         

        Speed is n0 subsitute fnor accurancy

         



      • Kevin Callahan
        As long as there are representatives from the team in the developer and test capabilities this approach seems sound. If this condition is not true, the issues
        Message 3 of 25 , Aug 27, 2013
        • 0 Attachment
          As long as there are representatives from the team in the developer and test capabilities this approach seems sound. If this condition is not true, the issues are many :/

          As the stories are broken down and clarified, involving the whole team for sizing, enforcement of ready criteria, shared understanding, etc, is required if they're to succeed in high quality implementation.

          -k


          On Aug 27, 2013, at 2:58 AM, Richard Griffiths wrote:

           

          Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

           

          Shouldn’t the whole team be involved in these exercises, not the chosen few?

           

          --

          Richard

           

          Speed is n0 subsitute fnor accurancy

           



          Kevin Callahan
          ---------------------------------
          Enterprise Agile Coach
          LiveWorld

          Direct   +1 (207) 691-2997
          Skype   kevmocal

          Follow Us   Facebook | Twitter | LinkedIn

        • srinivas chillara
          Hello Richard, Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best
          Message 4 of 25 , Aug 27, 2013
          • 0 Attachment
            Hello Richard,
            Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

            However, sometimes it is difficult to get everyone in on these "work ahead" sessions/meetings.
            So we can rotate people in/out of this. A good ScrumMaster will facilitate this (possibly using some form of volunteering). In addition a good Scrum Master can keep an eye out for problems that may be originating from the "work ahead" team. 

            Of course we can inspect and adapt, as always.

            cheers
            Srinivas
            http://ceezone.wordpress.com



            From: Richard Griffiths <richard@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Tuesday, 27 August 2013 12:28 PM
            Subject: [scrumdevelopment] Concept of "work ahead" team

             
            Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
             
            Shouldn’t the whole team be involved in these exercises, not the chosen few?
             
            --
            Richard
             
            Speed is n0 subsitute fnor accurancy
             


          • Cass Dalton
            It s not just the hierarchy. The team contributes to the story decomposition, estimation, and refinement because they re the ones that will be doing the work.
            Message 5 of 25 , Aug 27, 2013
            • 0 Attachment
              It's not just the hierarchy.  The team contributes to the story decomposition, estimation, and refinement because they're the ones that will be doing the work.  They are the ones with skin in the game.  Having someone else refine stories leads to unrealistic estimates and allows ambiguities about the Definition of Done to slip through.  It short circuits the "Conversation" part of the 3 C's of user stories because the team is not part of the story conversation.  It also adds back some of the waterfall handoffs in the form of analysts and architects handing off work to developers.

              If you find yourself falling into the practice because iteration sessions are too long and devs get bored, then 1) have them attend a grooming session elsewhere in the iteration, and 2) make sure that you're not splitting work along resource/architecture boundaries.  If you split work along architecture and resource boundaries, the UI guy will be board while the team discusses non-UI stories, but that's an indication that the work is being stovepiped in the old waterfall fashion.

              If you find yourself falling into the practice because the dev team feels like they can't meet their commitments if they take time out of the iteration to refine stories, then you should probably reevaluate the pressures that the PO and SM are putting on the team.


              On Tue, Aug 27, 2013 at 10:47 AM, srinivas chillara <ceezone@...> wrote:
               

              Hello Richard,
              Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

              However, sometimes it is difficult to get everyone in on these "work ahead" sessions/meetings.
              So we can rotate people in/out of this. A good ScrumMaster will facilitate this (possibly using some form of volunteering). In addition a good Scrum Master can keep an eye out for problems that may be originating from the "work ahead" team. 

              Of course we can inspect and adapt, as always.

              cheers
              Srinivas



              From: Richard Griffiths <richard@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Tuesday, 27 August 2013 12:28 PM
              Subject: [scrumdevelopment] Concept of "work ahead" team

               
              Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
               
              Shouldn’t the whole team be involved in these exercises, not the chosen few?
               
              --
              Richard
               
              Speed is n0 subsitute fnor accurancy
               



            • Richard Griffiths
              Michael, Srinivas, Madhur Thanks for the responses (condensed for brevity) ... Actually the sub team has formed from within the team - PO, BA and architect,
              Message 6 of 25 , Aug 27, 2013
              • 0 Attachment

                Michael, Srinivas, Madhur

                 

                Thanks for the responses (condensed for brevity)

                 

                > When you refer to the "chosen few" I'm curious who is doing that choosing.

                 

                Actually the sub team has formed from within the team - PO, BA and architect, they very much look at up-coming stories to get them in some form of shape for the whole team to review them at story sizing/grooming sessions.

                 

                > A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

                 

                We do have some time-zone issues and not everyone is able to meet to plan for the future and groom the backlog on a daily basis; this way we get team input, and as noted, we do rotate people in and out, but it seems to be working.

                 

                We have planned grooming sessions (one per week) where everyone attends and we refine and size as appropriate

                 

                I was more concerned that there was an expectation that the sub-team/work ahead group would estimate the stories.

                 

                My answer was, fine, as long as they, and they only, are happy to take on the work J

                 

                Richard

                 


                From: Richard Griffiths <richard@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Tuesday, 27 August 2013 12:28 PM
                Subject: [scrumdevelopment] Concept of "work ahead" team

                 

                 

                Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

                 

                Shouldn’t the whole team be involved in these exercises, not the chosen few?

                 

                --

                Richard

                 

                Speed is n0 subsitute fnor accurancy

                 

                 

              • srinivas chillara
                The last point made is a good one.  However much of the conversation for a user story taken up in a given sprint happens during the sprint. So no worries
                Message 7 of 25 , Aug 27, 2013
                • 0 Attachment
                  The last point made is a good one. 
                  However much of the conversation for a user story taken up in a given sprint happens during the sprint. So no worries there. 

                  I don't think the "look ahead" team mentioned by Richard was an exclusive set. 

                  cheers
                  srinivas


                  From: Cass Dalton <cassdalton73@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Tuesday, 27 August 2013 9:10 PM
                  Subject: Re: [scrumdevelopment] Concept of "work ahead" team

                   
                  It's not just the hierarchy.  The team contributes to the story decomposition, estimation, and refinement because they're the ones that will be doing the work.  They are the ones with skin in the game.  Having someone else refine stories leads to unrealistic estimates and allows ambiguities about the Definition of Done to slip through.  It short circuits the "Conversation" part of the 3 C's of user stories because the team is not part of the story conversation.  It also adds back some of the waterfall handoffs in the form of analysts and architects handing off work to developers.

                  If you find yourself falling into the practice because iteration sessions are too long and devs get bored, then 1) have them attend a grooming session elsewhere in the iteration, and 2) make sure that you're not splitting work along resource/architecture boundaries.  If you split work along architecture and resource boundaries, the UI guy will be board while the team discusses non-UI stories, but that's an indication that the work is being stovepiped in the old waterfall fashion.

                  If you find yourself falling into the practice because the dev team feels like they can't meet their commitments if they take time out of the iteration to refine stories, then you should probably reevaluate the pressures that the PO and SM are putting on the team.


                  On Tue, Aug 27, 2013 at 10:47 AM, srinivas chillara <ceezone@...> wrote:
                   
                  Hello Richard,
                  Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

                  However, sometimes it is difficult to get everyone in on these "work ahead" sessions/meetings.
                  So we can rotate people in/out of this. A good ScrumMaster will facilitate this (possibly using some form of volunteering). In addition a good Scrum Master can keep an eye out for problems that may be originating from the "work ahead" team. 

                  Of course we can inspect and adapt, as always.

                  cheers
                  Srinivas



                  From: Richard Griffiths <richard@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Tuesday, 27 August 2013 12:28 PM
                  Subject: [scrumdevelopment] Concept of "work ahead" team

                   
                  Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
                   
                  Shouldn’t the whole team be involved in these exercises, not the chosen few?
                   
                  --
                  Richard
                   
                  Speed is n0 subsitute fnor accurancy
                   





                • Kurt Häusler
                  Hi Richard, I have heard the term be used to describe something else, other than grooming, or backlog refinement as it is now called. I think it is ok to have
                  Message 8 of 25 , Aug 27, 2013
                  • 0 Attachment
                    Hi Richard,

                    I have heard the term be used to describe something else, other than grooming, or backlog refinement as it is now called. I think it is ok to have a subset of the team do this.

                    To me "work ahead" has another connotation. Where the roles you mention essentially solve the problem, they have the discussions with the customer, they prepare assets, they write specifications, they design the UI, maybe even go so far as producing or modifying wireframes or mockups.

                    it is a horrible horrible anti-pattern. If the team receives essentially solved problems to merely type in then they will be extremely demotivated.

                    It is also highly wasteful, as there is no guarantee this work will even be used.

                    There is plenty of time within the sprint to do this work, together as a team and if there isn't the stories need to be made smaller.

                    Kurt

                    On 27 Aug 2013, at 09:58, "Richard Griffiths" <richard@...> wrote:

                    >
                    > Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
                    >
                    >
                    >
                    > Shouldn’t the whole team be involved in these exercises, not the chosen few?
                  • Peter Trudelle
                    While I largely agree with Kurt s characterization of the extreme version of such meetings, I think that that a simple form of them may be useful at early
                    Message 9 of 25 , Aug 28, 2013
                    • 0 Attachment
                      While I largely agree with Kurt's characterization of the extreme
                      version of such meetings, I think that that a simple form of them may be
                      useful at early stages of an organization's transition to Agile. I've
                      recently set a couple of these up, calling them "Epic Time", but more
                      along the lines of Customer Teams, or Three Amigos, to source and refine
                      stories to ensure they are ready for the team to take up at Story Time.
                      The Scrum teams had been agonizing over stories that weren't ready,
                      spending 30+ minutes per story trying to figure out what they might
                      mean, with the POs trying to act as intermediary with
                      customers/stakeholders, who were not engaging directly with the teams.
                      These Epic Time meetings involve the PO, customers/stakeholders, SMEs,
                      and team members sent by the team to represent development, testing, and
                      user experience. We try to ensure a flow of higher-quality stories to
                      the team, so as not to waste the entire team's time.

                      Peter

                      On 8/27/13 9:54 PM, Kurt Häusler wrote:
                      > Hi Richard,
                      >
                      > I have heard the term be used to describe something else, other than grooming, or backlog refinement as it is now called. I think it is ok to have a subset of the team do this.
                      >
                      > To me "work ahead" has another connotation. Where the roles you mention essentially solve the problem, they have the discussions with the customer, they prepare assets, they write specifications, they design the UI, maybe even go so far as producing or modifying wireframes or mockups.
                      >
                      > it is a horrible horrible anti-pattern. If the team receives essentially solved problems to merely type in then they will be extremely demotivated.
                      >
                      > It is also highly wasteful, as there is no guarantee this work will even be used.
                      >
                      > There is plenty of time within the sprint to do this work, together as a team and if there isn't the stories need to be made smaller.
                      >
                      > Kurt
                      >
                      > On 27 Aug 2013, at 09:58, "Richard Griffiths" <richard@...> wrote:
                      >
                      >> Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
                      >>
                      >>
                      >>
                      >> Shouldn’t the whole team be involved in these exercises, not the chosen few?
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > To Post a message, send it to: scrumdevelopment@...
                      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                      >
                      >
                      >
                    • Prashant Pund
                      Hello Richard, We have seen the limitations of such a group ( I reserve the term Team). In our case, the group consisted of a few senior team members plus
                      Message 10 of 25 , Aug 28, 2013
                      • 0 Attachment

                        Hello Richard,
                        We have seen the limitations of such a group ( I reserve the term Team). In our case, the group consisted of a few senior team members plus other stakeholders like Engg Manager.The estimates of the stories is based on understanding and in turn conversation within this group. The limitation is about transfer of this understanding to the Team. There are disagreements about the work involved and estimates. Also, this group, later on, becomes the one who " assigns" the job to the Team.
                        If appropriate care is taken about collaboration between this group and the Team; these limitations can be overcome.
                        The idea of rotating the members suggested by Srinivas in this discussion sounds good and we'll try it.
                        Prashant Pund
                        AgileSoft Methodologies
                        www.agilesoft.in

                        On Aug 27, 2013 8:17 PM, "srinivas chillara" <ceezone@...> wrote:
                        >
                        >  
                        >
                        > Hello Richard,
                        > Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 
                        >
                        > However, sometimes it is difficult to get everyone in on these "work ahead" sessions/meetings.
                        > So we can rotate people in/out of this. A good ScrumMaster will facilitate this (possibly using some form of volunteering). In addition a good Scrum Master can keep an eye out for problems that may be originating from the "work ahead" team. 
                        >
                        > Of course we can inspect and adapt, as always.
                        >
                        > cheers
                        > Srinivas
                        > http://ceezone.wordpress.com
                        >
                        >
                        > ________________________________
                        > From: Richard Griffiths <richard@...>
                        > To: scrumdevelopment@yahoogroups.com
                        > Sent: Tuesday, 27 August 2013 12:28 PM
                        > Subject: [scrumdevelopment] Concept of "work ahead" team
                        >
                        >  
                        > Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
                        >  
                        > Shouldn’t the whole team be involved in these exercises, not the chosen few?
                        >  
                        > --
                        > Richard
                        >  
                        > Speed is n0 subsitute fnor accurancy
                        >  
                        >
                        >
                        >

                      • Alex Pereira
                        I Agree with Peter here. Although my Agile experience is far lower than a lot of people in this group, I came to realize that it probably depends on what stage
                        Message 11 of 25 , Aug 29, 2013
                        • 0 Attachment
                          I Agree with Peter here. Although my Agile experience is far lower than a lot of people in this group, I came to realize that it probably depends on what stage of Agile the organization is, and also, the domain experience of developers/QA on the team.

                          Take for example my current job (as a sr. dev), in which I have been for only 3 1/2 months - I was also hired for my previous experience as a Scrum Master. The company is in the early (really crawling) stages of Scrum, and the VP wants all developers/QA to participate in the backlog refining meetings. This is by far the worse arrangement, which I have been trying to persuade them to change.

                          My team consists of:
                          1 Team Lead/Sr. Dev - been here for over 5 years, so lots of domain knowledge
                          1 Jr. Dev - been here about 2 years
                          1 Mid Dev. - been here about 6 months
                          1 Sr Dev (me) - been here about 4 months
                          1 Jr. Dev - been here about 2 months
                          1 Sr QA - been here for over 9 years, so lots of domain knowledge

                          We have about 2-3 backlog refining meetings each week, and for the most part, with the exception of the team lead and QA, the rest of the team have very little input to give. Which means we are wasting time. I understand we have a lot of issues to overcome here, but for the context of this email, I will just stick with the "work ahead" team concept.

                          Based on my past and my current experience, I think the best "lean" approach would be to have a group consisting of the most knowledgeable team members (team lead/sr. dev + QA), together with PO, UX, and other stakeholders create and expand user stories as much as they can. We could probably cut down meetings involving all devs/qa to 1 per week, in which we could discuss the approach to be taken (further refining) and also estimate. I believe this would be the most lean and optimal approach. 



                          Alex Pereira
                          http://www.brainstack.net/ (Professional Blog)


                          From: Peter Trudelle <trudelle@...>
                          To: scrumdevelopment@yahoogroups.com
                          Cc: Kurt Häusler <kurt.haeusler@...>
                          Sent: Wednesday, August 28, 2013 8:43 PM
                          Subject: Re: [scrumdevelopment] Concept of "work ahead" team

                          While I largely agree with Kurt's characterization of the extreme
                          version of such meetings, I think that that a simple form of them may be
                          useful at early stages of an organization's transition to Agile.  I've
                          recently set a couple of these up, calling them "Epic Time", but more
                          along the lines of Customer Teams, or Three Amigos, to source and refine
                          stories to ensure they are ready for the team to take up at Story Time. 
                          The Scrum teams had been agonizing over stories that weren't ready,
                          spending 30+ minutes per story trying to figure out what they might
                          mean, with the POs trying to act as intermediary with
                          customers/stakeholders, who were not engaging directly with the teams.
                          These Epic Time meetings involve the PO, customers/stakeholders, SMEs,
                          and team members sent by the team to represent development, testing, and
                          user experience.  We try to ensure a flow of  higher-quality stories to
                          the team, so as not to waste the entire team's time.

                          Peter
                        • Jesse Houwing
                          Keep in mind that these sessions are not only meant to get a clear backlog item, but also to transfer knowledge from the domain expert, stakeholders and po to
                          Message 12 of 25 , Aug 31, 2013
                          • 0 Attachment
                            Keep in mind that these sessions are not only meant to get a clear backlog item, but also to transfer knowledge from the domain expert, stakeholders and po to all team members.

                            Since the other team members have relatively recently started, they should have a gap in their domain knowledge, these sessions should give them a lit of insights when the contents are presented in a way that really explains them.

                            It might feel like a lot of unrequired work to get the backlog in shape, but it is a lot of really needed work to get your team members in shape.

                            Get them to ask questions. Get them,to ask the same question over and until you get to the real why. That way your team members will be able to understand and carry the vision in all their work.

                            Sent from my Windows Phone

                            From: Alex Pereira
                            Sent: ‎29-‎8-‎2013 15:05
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] Concept of "work ahead" team



                            I Agree with Peter here. Although my Agile experience is far lower than a lot of people in this group, I came to realize that it probably depends on what stage of Agile the organization is, and also, the domain experience of developers/QA on the team.

                            Take for example my current job (as a sr. dev), in which I have been for only 3 1/2 months - I was also hired for my previous experience as a Scrum Master. The company is in the early (really crawling) stages of Scrum, and the VP wants all developers/QA to participate in the backlog refining meetings. This is by far the worse arrangement, which I have been trying to persuade them to change.

                            My team consists of:
                            1 Team Lead/Sr. Dev - been here for over 5 years, so lots of domain knowledge
                            1 Jr. Dev - been here about 2 years
                            1 Mid Dev. - been here about 6 months
                            1 Sr Dev (me) - been here about 4 months
                            1 Jr. Dev - been here about 2 months
                            1 Sr QA - been here for over 9 years, so lots of domain knowledge

                            We have about 2-3 backlog refining meetings each week, and for the most part, with the exception of the team lead and QA, the rest of the team have very little input to give. Which means we are wasting time. I understand we have a lot of issues to overcome here, but for the context of this email, I will just stick with the "work ahead" team concept.

                            Based on my past and my current experience, I think the best "lean" approach would be to have a group consisting of the most knowledgeable team members (team lead/sr. dev + QA), together with PO, UX, and other stakeholders create and expand user stories as much as they can. We could probably cut down meetings involving all devs/qa to 1 per week, in which we could discuss the approach to be taken (further refining) and also estimate. I believe this would be the most lean and optimal approach. 



                            Alex Pereira
                            http://www.brainstack.net/ (Professional Blog)


                            From: Peter Trudelle <trudelle@...>
                            To: scrumdevelopment@yahoogroups.com
                            Cc: Kurt Häusler <kurt.haeusler@...>
                            Sent: Wednesday, August 28, 2013 8:43 PM
                            Subject: Re: [scrumdevelopment] Concept of "work ahead" team

                            While I largely agree with Kurt's characterization of the extreme
                            version of such meetings, I think that that a simple form of them may be
                            useful at early stages of an organization's transition to Agile.  I've
                            recently set a couple of these up, calling them "Epic Time", but more
                            along the lines of Customer Teams, or Three Amigos, to source and refine
                            stories to ensure they are ready for the team to take up at Story Time. 
                            The Scrum teams had been agonizing over stories that weren't ready,
                            spending 30+ minutes per story trying to figure out what they might
                            mean, with the POs trying to act as intermediary with
                            customers/stakeholders, who were not engaging directly with the teams.
                            These Epic Time meetings involve the PO, customers/stakeholders, SMEs,
                            and team members sent by the team to represent development, testing, and
                            user experience.  We try to ensure a flow of  higher-quality stories to
                            the team, so as not to waste the entire team's time.

                            Peter


                          • Alix Moghdam
                            *It seems that this team is helping the PO to create a better backlog. If so, I think it does not harm. But they should remain at the PO fields and boundaries:
                            Message 13 of 25 , Sep 3, 2013
                            • 0 Attachment
                              It seems that this team is helping the PO to create a better backlog. If so, I think it does not harm. But they should remain at the PO fields and boundaries: Defining Stories from business point of view and prioritizing them. And the PO should still be responsible about the final decisions. This team just helps him/her.
                              If this team falls into technical fields, then it could be an anti-pattern. They should not decide about implementation, design, and other development-related topics. 
                               
                              @Alix


                              On Tue, Aug 27, 2013 at 10:48 PM, Richard Griffiths <richard@...> wrote:
                               

                              Michael, Srinivas, Madhur

                               

                              Thanks for the responses (condensed for brevity)

                               

                              > When you refer to the "chosen few" I'm curious who is doing that choosing.

                               

                              Actually the sub team has formed from within the team - PO, BA and architect, they very much look at up-coming stories to get them in some form of shape for the whole team to review them at story sizing/grooming sessions.

                               

                              > A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

                               

                              We do have some time-zone issues and not everyone is able to meet to plan for the future and groom the backlog on a daily basis; this way we get team input, and as noted, we do rotate people in and out, but it seems to be working.

                               

                              We have planned grooming sessions (one per week) where everyone attends and we refine and size as appropriate

                               

                              I was more concerned that there was an expectation that the sub-team/work ahead group would estimate the stories.

                               

                              My answer was, fine, as long as they, and they only, are happy to take on the work J

                               

                              Richard

                               


                              From: Richard Griffiths <richard@...>
                              To: scrumdevelopment@yahoogroups.com
                              Sent: Tuesday, 27 August 2013 12:28 PM
                              Subject: [scrumdevelopment] Concept of "work ahead" team

                               

                               

                              Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

                               

                              Shouldn’t the whole team be involved in these exercises, not the chosen few?

                               

                              --

                              Richard

                               

                              Speed is n0 subsitute fnor accurancy

                               

                               


                            • Ron Jeffries
                              Alix, ... The team that does this helping is learning things. It would be better if the team that was doing the building could get that learning first hand.
                              Message 14 of 25 , Sep 3, 2013
                              • 0 Attachment
                                Alix,

                                On Sep 3, 2013, at 9:36 AM, Alix Moghdam <ali.moghadam@...> wrote:

                                It seems that this team is helping the PO to create a better backlog. If so, I think it does not harm. But they should remain at the PO fields and boundaries: Defining Stories from business point of view and prioritizing them. And the PO should still be responsible about the final decisions. This team just helps him/her.

                                The team that does this helping is learning things. It would be better if the team that was doing the building could get that learning first hand.

                                Ron Jeffries
                                I know we always like to say it'll be easier to do it now than it
                                will be to do it later. Not likely. I plan to be smarter later than
                                I am now, so I think it'll be just as easy later, maybe even easier.
                                Why pay now when we can pay later?

                              • Cass Dalton
                                I still feel that this makes the dev team lose out on some of that good conversation. Understanding what makes a story better gives the dev team valuable
                                Message 15 of 25 , Sep 3, 2013
                                • 0 Attachment

                                  I still feel that this makes the dev team lose out on some of that good conversation.  Understanding what makes a story "better" gives the dev team valuable context for that story

                                  On Sep 3, 2013 9:52 AM, "Alix Moghdam" <ali.moghadam@...> wrote:
                                   

                                  It seems that this team is helping the PO to create a better backlog. If so, I think it does not harm. But they should remain at the PO fields and boundaries: Defining Stories from business point of view and prioritizing them. And the PO should still be responsible about the final decisions. This team just helps him/her.
                                  If this team falls into technical fields, then it could be an anti-pattern. They should not decide about implementation, design, and other development-related topics. 
                                   
                                  @Alix


                                  On Tue, Aug 27, 2013 at 10:48 PM, Richard Griffiths <richard@...> wrote:
                                   

                                  Michael, Srinivas, Madhur

                                   

                                  Thanks for the responses (condensed for brevity)

                                   

                                  > When you refer to the "chosen few" I'm curious who is doing that choosing.

                                   

                                  Actually the sub team has formed from within the team - PO, BA and architect, they very much look at up-coming stories to get them in some form of shape for the whole team to review them at story sizing/grooming sessions.

                                   

                                  > A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

                                   

                                  We do have some time-zone issues and not everyone is able to meet to plan for the future and groom the backlog on a daily basis; this way we get team input, and as noted, we do rotate people in and out, but it seems to be working.

                                   

                                  We have planned grooming sessions (one per week) where everyone attends and we refine and size as appropriate

                                   

                                  I was more concerned that there was an expectation that the sub-team/work ahead group would estimate the stories.

                                   

                                  My answer was, fine, as long as they, and they only, are happy to take on the work J

                                   

                                  Richard

                                   


                                  From: Richard Griffiths <richard@...>
                                  To: scrumdevelopment@yahoogroups.com
                                  Sent: Tuesday, 27 August 2013 12:28 PM
                                  Subject: [scrumdevelopment] Concept of "work ahead" team

                                   

                                   

                                  Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

                                   

                                  Shouldn’t the whole team be involved in these exercises, not the chosen few?

                                   

                                  --

                                  Richard

                                   

                                  Speed is n0 subsitute fnor accurancy

                                   

                                   


                                • George Dinwiddie
                                  Hi, Richard, ... I ve found that grooming stories with the whole team can drag on and on, accomplishing relatively little and frustrating everyone. On the
                                  Message 16 of 25 , Sep 3, 2013
                                  • 0 Attachment
                                    Hi, Richard,

                                    On 8/27/13 2:58 AM, Richard Griffiths wrote:
                                    >
                                    >
                                    > Hi all, I’ve started to hear this more often – the “work ahead” team
                                    > being a smaller group out of the team (BA, Architect, UX) who will groom
                                    > the stories, relatively size them, have them ready for the team to do
                                    > further work on.
                                    >
                                    > Shouldn’t the whole team be involved in these exercises, not the chosen few?

                                    I've found that grooming stories with the whole team can drag on and on,
                                    accomplishing relatively little and frustrating everyone. On the other
                                    hand, it's important that everyone have some involvement. It's
                                    particularly important that someone doing the work not be handed an
                                    estimate made by someone not doing the work.

                                    About 5 years ago we pioneered a "Three Amigos" process at a client
                                    where a small group containing the product owner, a tester, and a
                                    programmer (and sometimes more, particularly UX in that client) would
                                    discuss a story or two to get it clear on the details. Today I recommend
                                    that this discussion result in acceptance scenarios that clarify the
                                    story and indicate minimum acceptance criteria. Often there are many
                                    such scenarios, and the story can be split along the lines of the scenarios.

                                    Different sets of "Three Amigos" would work on grooming different
                                    stories on different days, giving everybody involvement in the process
                                    but not everybody involved in the same stories.

                                    This clarification would happen before the planning meeting. At the
                                    planning meeting, everyone took part in estimation and determining how
                                    many stories fit. The clarity brought by having explicit examples in the
                                    acceptance scenarios made the estimation and planning proceed much more
                                    quickly.

                                    You might be interested in this article from Better Software:
                                    http://manage.techwell.com/articles/weekly/three-amigos

                                    - George

                                    --
                                    ----------------------------------------------------------------------
                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                    Software Development http://www.idiacomputing.com
                                    Consultant and Coach http://www.agilemaryland.org
                                    ----------------------------------------------------------------------
                                  • Adrian Howard
                                    ... Are there other ways to drop the annoyance level? For example: * grooming less at a time (my preference) * things like affinity estimation
                                    Message 17 of 25 , Sep 3, 2013
                                    • 0 Attachment
                                      On 3 September 2013 17:52, George Dinwiddie <lists@...> wrote:
                                      > I've found that grooming stories with the whole team can drag on and on,
                                      > accomplishing relatively little and frustrating everyone. On the other
                                      > hand, it's important that everyone have some involvement. It's
                                      > particularly important that someone doing the work not be handed an
                                      > estimate made by someone not doing the work.

                                      Are there other ways to drop the annoyance level? For example:

                                      * grooming less at a time (my preference)
                                      * things like affinity estimation
                                      (http://kanemar.com/2008/04/21/scrum-trainers-gathering-44-affinity-estimating/)

                                      Not arguing that 3 Amigos is a useful approach... but as years go buy
                                      I'm more and more hesitant about approaches that stop the whole team
                                      participating.

                                      Cheers,

                                      Adrian
                                      --
                                      adrianh@... / +44 (0)7752 419080 / @adrianh / quietstars.com
                                      Subscribe to the latest Agile & Lean UX news here > http://is.gd/KREt5S
                                    • Ron Jeffries
                                      Hi Adrian, ... I tend to agree. Limiting knowledge / learning to a few seems off to me. Ron Jeffries www.XProgramming.com I know we always like to say it ll be
                                      Message 18 of 25 , Sep 3, 2013
                                      • 0 Attachment
                                        Hi Adrian,

                                        On Sep 3, 2013, at 8:34 PM, Adrian Howard <adrianh@...> wrote:

                                        Not arguing that 3 Amigos is a useful approach... but as years go buy
                                        I'm more and more hesitant about approaches that stop the whole team
                                        participating.

                                        I tend to agree. Limiting knowledge / learning to a few seems off to me.

                                        Ron Jeffries
                                        I know we always like to say it'll be easier to do it now than it
                                        will be to do it later. Not likely. I plan to be smarter later than
                                        I am now, so I think it'll be just as easy later, maybe even easier.
                                        Why pay now when we can pay later?

                                      • Adam Sroka
                                        My interpretation of three amigos is that it does not preclude whole team participation but describes the three viewpoints required to have a quorum on any
                                        Message 19 of 25 , Sep 3, 2013
                                        • 0 Attachment
                                          My interpretation of three amigos is that it does not preclude whole team participation but describes the three viewpoints required to have a quorum on any story. On a high functioning team anyone should be able to represent any of the three. So, you need a pair to have the conversation and the customer/PO to make the final call. 

                                          On Tuesday, September 3, 2013, Adrian Howard wrote:
                                           

                                          On 3 September 2013 17:52, George Dinwiddie <lists@...> wrote:
                                          > I've found that grooming stories with the whole team can drag on and on,
                                          > accomplishing relatively little and frustrating everyone. On the other
                                          > hand, it's important that everyone have some involvement. It's
                                          > particularly important that someone doing the work not be handed an
                                          > estimate made by someone not doing the work.

                                          Are there other ways to drop the annoyance level? For example:

                                          * grooming less at a time (my preference)
                                          * things like affinity estimation
                                          (http://kanemar.com/2008/04/21/scrum-trainers-gathering-44-affinity-estimating/)

                                          Not arguing that 3 Amigos is a useful approach... but as years go buy
                                          I'm more and more hesitant about approaches that stop the whole team
                                          participating.

                                          Cheers,

                                          Adrian
                                          --
                                          adrianh@... / +44 (0)7752 419080 / @adrianh / quietstars.com
                                          Subscribe to the latest Agile & Lean UX news here > http://is.gd/KREt5S

                                        • Adam Sroka
                                          Perhaps, if we are planning in a manner that feels like it is a waste of time for some of the folks on the team, it is, in fact, a waste of the time for
                                          Message 20 of 25 , Sep 3, 2013
                                          • 0 Attachment
                                            Perhaps, if we are planning in a manner that feels like it is a waste of time for some of the folks on the team, it is, in fact, a waste of the time for everyone on the team, and we should find a leaner and more effective way to plan. Conversations that are valuable are not a waste of anyone's time. 


                                            On Tue, Sep 3, 2013 at 8:38 PM, Ron Jeffries <ronjeffries@...> wrote:
                                             

                                            Hi Adrian,


                                            On Sep 3, 2013, at 8:34 PM, Adrian Howard <adrianh@...> wrote:

                                            Not arguing that 3 Amigos is a useful approach... but as years go buy
                                            I'm more and more hesitant about approaches that stop the whole team
                                            participating.

                                            I tend to agree. Limiting knowledge / learning to a few seems off to me.


                                            Ron Jeffries
                                            I know we always like to say it'll be easier to do it now than it
                                            will be to do it later. Not likely. I plan to be smarter later than
                                            I am now, so I think it'll be just as easy later, maybe even easier.
                                            Why pay now when we can pay later?


                                          • Adrian Howard
                                            ... That feels right to me. Cheers, Adrian -- adrianh@quietstars.com / +44 (0)7752 419080 / @adrianh / quietstars.com Join my Fundamentals of Lean UX workshop,
                                            Message 21 of 25 , Sep 3, 2013
                                            • 0 Attachment

                                              On 4 September 2013 02:05, Adam Sroka <adam.sroka@...> wrote:
                                              Perhaps, if we are planning in a manner that feels like it is a waste of time for some of the folks on the team, it is, in fact, a waste of the time for everyone on the team, and we should find a leaner and more effective way to plan. Conversations that are valuable are not a waste of anyone's time. 

                                              That feels right to me.

                                              Cheers,

                                              Adrian
                                              -- 
                                              adrianh@... / +44 (0)7752 419080 / @adrianh / quietstars.com
                                              Join my Fundamentals of Lean UX workshop, Sep 4, http://uxcambridge.net

                                            • George Dinwiddie
                                              Adrian, ... That s part of this. But when we first did this, it was also part of the whole team exercise. ... Estimating is not part of the grooming. That s
                                              Message 22 of 25 , Sep 3, 2013
                                              • 0 Attachment
                                                Adrian,

                                                On 9/3/13 8:34 PM, Adrian Howard wrote:
                                                > On 3 September 2013 17:52, George Dinwiddie <lists@...> wrote:
                                                >> I've found that grooming stories with the whole team can drag on and on,
                                                >> accomplishing relatively little and frustrating everyone. On the other
                                                >> hand, it's important that everyone have some involvement. It's
                                                >> particularly important that someone doing the work not be handed an
                                                >> estimate made by someone not doing the work.
                                                >
                                                > Are there other ways to drop the annoyance level? For example:
                                                >
                                                > * grooming less at a time (my preference)

                                                That's part of this. But when we first did this, it was also part of the
                                                whole team exercise.

                                                > * things like affinity estimation
                                                > (http://kanemar.com/2008/04/21/scrum-trainers-gathering-44-affinity-estimating/)

                                                Estimating is not part of the grooming. That's generally done at the
                                                planning meeting by the whole team. And, yes, I find affinity estimating
                                                a better technique than most. I've considered counting the scenarios. I
                                                generally recommend calling them all "1."

                                                > Not arguing that 3 Amigos is a useful approach... but as years go buy
                                                > I'm more and more hesitant about approaches that stop the whole team
                                                > participating.

                                                I suppose you can do mob programming, but most teams don't have
                                                everybody working together on every task.

                                                The Three Amigos approach doesn't stop the whole team from
                                                participating. It does gain a lot of clarity in small group discussions,
                                                but that clarity is then brought to the whole team at planning time. The
                                                whole team is then able to assess each story more quickly. In my
                                                experience, if people think that important scenarios are missing,
                                                they'll generally say something.

                                                The use of acceptance scenarios makes it easy to keep straight on what
                                                is in a particular story, and what is out. Confusion over what's in and
                                                what's out seems to cause most of the problems in whole-team grooming
                                                exercises, in my experience. After a discussion that says "this part is
                                                in and that part is out," invariably someone brings up the need for
                                                "that part" later in the discussion.

                                                Breaking into small groups and bringing it back to the larger group is a
                                                time-honored and effective facilitation technique. But if you're
                                                uncomfortable with it, by all means try it with the whole team. I think
                                                the most important part of this is generating explicit scenarios to
                                                illustrate the story. Doing so more efficiently is much less important.

                                                - George

                                                --
                                                ----------------------------------------------------------------------
                                                * George Dinwiddie * http://blog.gdinwiddie.com
                                                Software Development http://www.idiacomputing.com
                                                Consultant and Coach http://www.agilemaryland.org
                                                ----------------------------------------------------------------------
                                              • George Dinwiddie
                                                Ron, ... That would seem off to me, also. That s not what I recommend. - George -- ... * George Dinwiddie * http://blog.gdinwiddie.com
                                                Message 23 of 25 , Sep 3, 2013
                                                • 0 Attachment
                                                  Ron,

                                                  On 9/3/13 8:38 PM, Ron Jeffries wrote:
                                                  >
                                                  >
                                                  > Hi Adrian,
                                                  >
                                                  > On Sep 3, 2013, at 8:34 PM, Adrian Howard <adrianh@...
                                                  > <mailto:adrianh@...>> wrote:
                                                  >
                                                  >> Not arguing that 3 Amigos is a useful approach... but as years go buy
                                                  >> I'm more and more hesitant about approaches that stop the whole team
                                                  >> participating.
                                                  >
                                                  > I tend to agree. Limiting knowledge / learning to a few seems off to me.

                                                  That would seem off to me, also. That's not what I recommend.

                                                  - George

                                                  --
                                                  ----------------------------------------------------------------------
                                                  * George Dinwiddie * http://blog.gdinwiddie.com
                                                  Software Development http://www.idiacomputing.com
                                                  Consultant and Coach http://www.agilemaryland.org
                                                  ----------------------------------------------------------------------
                                                • George Dinwiddie
                                                  Adam, ... Yes, it s viewpoints, not job roles, that count. At a minimum, - someone to keep an eye on the business desires - someone to keep an eye on
                                                  Message 24 of 25 , Sep 3, 2013
                                                  • 0 Attachment
                                                    Adam,

                                                    On 9/3/13 8:54 PM, Adam Sroka wrote:
                                                    >
                                                    >
                                                    > My interpretation of three amigos is that it does not preclude whole
                                                    > team participation but describes the three viewpoints required to have a
                                                    > quorum on any story. On a high functioning team anyone should be able to
                                                    > represent any of the three. So, you need a pair to have the conversation
                                                    > and the customer/PO to make the final call.

                                                    Yes, it's viewpoints, not job roles, that count. At a minimum,
                                                    - someone to keep an eye on the business desires
                                                    - someone to keep an eye on implementation issues
                                                    - someone to keep an eye on edge cases and what might go wrong.
                                                    I've found it better if these viewpoints are embodied in three separate
                                                    people in the discussion. Often one person CAN hold these three
                                                    viewpoints, but it's hard to do so simultaneously. And I caution people
                                                    that there may be other important viewpoints. Some common examples:
                                                    - someone to keep an eye on UX issues
                                                    - someone to keep an eye on security issues
                                                    - someone to keep an eye on specialized business desires that are
                                                    separate from user needs, such as accounting or legal

                                                    - George

                                                    --
                                                    ----------------------------------------------------------------------
                                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                                    Software Development http://www.idiacomputing.com
                                                    Consultant and Coach http://www.agilemaryland.org
                                                    ----------------------------------------------------------------------
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.