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

Completing Stories (i.e. swarming vs filling the pipeline)

Expand Messages
  • JackM
    I have some developers struggling with the dilema wrt completing stories in a sprint - i.e. meat your goal all crossing the goal line together vs keeping
    Message 1 of 9 , Nov 28, 2012
    • 0 Attachment
      I have some developers struggling with the dilema wrt completing stories in a sprint - i.e. meat your goal all crossing the goal line together vs keeping developers pipeline full

      I am looking for some good arguments to support this.

      Thanks
      Jack
    • Alan Dayley
      Please elaborate further. More context is needed to form a possible answer. Especially about keeping the developers pipeline full. Alan
      Message 2 of 9 , Nov 28, 2012
      • 0 Attachment
        Please elaborate further.  More context is needed to form a possible answer.  Especially about "keeping the developers pipeline full."

        Alan



        On Wed, Nov 28, 2012 at 10:15 AM, JackM <jack@...> wrote:
         

        I have some developers struggling with the dilema wrt completing stories in a sprint - i.e. meat your goal all crossing the goal line together vs keeping developers pipeline full

        I am looking for some good arguments to support this.

        Thanks
        Jack


      • Bret Wortman
        It seems to me that the goal isn t so much to keep a developer s pipeline full as it is to keep developers working. There s a natural end to each sprint at
        Message 3 of 9 , Nov 28, 2012
        • 0 Attachment
          It seems to me that the goal isn't so much to keep a developer's pipeline full as it is to keep developers working. There's a natural end to each sprint at which all the work ceases, the pipes (well, the sprint backlog, anyway) is empty and everyone breathes for a moment. Then you refill the pipe from the water tower (the product backlog) and start over again.

          During the sprint, I shouldn't have my pipe filled with claimed but unstarted work. I should be grabbing one thing at a time and completing it before moving on. Otherwise, by pre-claiming work, I'm limiting what others can do during the sprint and risking not being able to complete everything *I* signed up for.

          It helps to think of this from the team's perspective, not an individual's. If that's your issue, anyway. It's the team pipe that matters, so swarming to help someone complete a task before sprint's end is a good thing -- having a backlog of work that's all for Joe to do is risky.

          If I've missed the mark completely, please give us some additional detail.


          On Wed, Nov 28, 2012 at 12:15 PM, JackM <jack@...> wrote:
           

          I have some developers struggling with the dilema wrt completing stories in a sprint - i.e. meat your goal all crossing the goal line together vs keeping developers pipeline full

          I am looking for some good arguments to support this.

          Thanks
          Jack




          --
          Bret Wortman
          The Damascus Group
          Fairfax, VA

        • JackM
          Very relevant and I get that, the issues is figuring out the best way to convince the team. So the discussion this senior developer had with me is he is
          Message 4 of 9 , Nov 28, 2012
          • 0 Attachment
            Very relevant and I get that, the issues is figuring out the best way to convince the team.

            So the discussion this senior developer had with me is he is worrying about his longer release commitments and getting that started so as to get ahead.

            The problem I see with this approach is the most important things get finished later rather than sooner. The whole swarming thing seems un-natural to them.

            If they truly have nothing more to do in the current Sprint, perhaps they could start some spike stories to get ahead for the next sprint.

            But in terms of flow, i think this approach is not good. i.e. you end up potentially with stockpiles on qa's plate.

            --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret.wortman@...> wrote:
            >
            > It seems to me that the goal isn't so much to keep a developer's pipeline
            > full as it is to keep developers working. There's a natural end to each
            > sprint at which all the work ceases, the pipes (well, the sprint backlog,
            > anyway) is empty and everyone breathes for a moment. Then you refill the
            > pipe from the water tower (the product backlog) and start over again.
            >
            > During the sprint, I shouldn't have my pipe filled with claimed but
            > unstarted work. I should be grabbing one thing at a time and completing it
            > before moving on. Otherwise, by pre-claiming work, I'm limiting what others
            > can do during the sprint and risking not being able to complete everything
            > *I* signed up for.
            >
            > It helps to think of this from the team's perspective, not an individual's.
            > If that's your issue, anyway. It's the team pipe that matters, so swarming
            > to help someone complete a task before sprint's end is a good thing --
            > having a backlog of work that's all for Joe to do is risky.
            >
            > If I've missed the mark completely, please give us some additional detail.
            >
            >
            > On Wed, Nov 28, 2012 at 12:15 PM, JackM <jack@...> wrote:
            >
            > > **
            > >
            > >
            > > I have some developers struggling with the dilema wrt completing stories
            > > in a sprint - i.e. meat your goal all crossing the goal line together vs
            > > keeping developers pipeline full
            > >
            > > I am looking for some good arguments to support this.
            > >
            > > Thanks
            > > Jack
            > >
            > >
            > >
            >
            >
            >
            > --
            > Bret Wortman
            > The Damascus Group
            > Fairfax, VA
            > http://bretwortman.com/
            > http://twitter.com/BretWortman
            >
          • Bret Wortman
            ...piles on qa s plate . You are doing QA within the sprint, right? Not as a separate activity? Cross-functional teams and all that? No roles within the team
            Message 5 of 9 , Nov 28, 2012
            • 0 Attachment
              "...piles on qa's plate".

              You are doing QA within the sprint, right? Not as a separate activity? Cross-functional teams and all that? No roles within the team but "developer", right?  ;-)

              I've fought with and cajoled senior (read: inflexible) developers with the same concern. "All this near-term stuff is great, but someone has to take the longer view and work toward the ultimate goal."

              Your senior developer needs to focus on the sprint at hand, and the commitment the team made for that sprint. Longer term goals are the most likely to change. The only thing that's guaranteed is that the work pulled by the team for this sprint.

              Ask him how many times the customer has changed his or her mind along the way? Your PO may rearrange the product backlog equally many times. And if you've set this up ideally (note: I've rarely managed this myself), you've not committed to a set of features by date "X", you've committed to an amount of work by date "X". What that work gets applied to is up to the PO, not your senior developer.


              On Wed, Nov 28, 2012 at 12:38 PM, JackM <jack@...> wrote:
               

              Very relevant and I get that, the issues is figuring out the best way to convince the team.

              So the discussion this senior developer had with me is he is worrying about his longer release commitments and getting that started so as to get ahead.

              The problem I see with this approach is the most important things get finished later rather than sooner. The whole swarming thing seems un-natural to them.

              If they truly have nothing more to do in the current Sprint, perhaps they could start some spike stories to get ahead for the next sprint.

              But in terms of flow, i think this approach is not good. i.e. you end up potentially with stockpiles on qa's plate.



              --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret.wortman@...> wrote:
              >
              > It seems to me that the goal isn't so much to keep a developer's pipeline
              > full as it is to keep developers working. There's a natural end to each
              > sprint at which all the work ceases, the pipes (well, the sprint backlog,
              > anyway) is empty and everyone breathes for a moment. Then you refill the
              > pipe from the water tower (the product backlog) and start over again.
              >
              > During the sprint, I shouldn't have my pipe filled with claimed but
              > unstarted work. I should be grabbing one thing at a time and completing it
              > before moving on. Otherwise, by pre-claiming work, I'm limiting what others
              > can do during the sprint and risking not being able to complete everything
              > *I* signed up for.
              >
              > It helps to think of this from the team's perspective, not an individual's.
              > If that's your issue, anyway. It's the team pipe that matters, so swarming
              > to help someone complete a task before sprint's end is a good thing --
              > having a backlog of work that's all for Joe to do is risky.
              >
              > If I've missed the mark completely, please give us some additional detail.
              >
              >
              > On Wed, Nov 28, 2012 at 12:15 PM, JackM <jack@...> wrote:
              >
              > > **

              > >
              > >
              > > I have some developers struggling with the dilema wrt completing stories
              > > in a sprint - i.e. meat your goal all crossing the goal line together vs
              > > keeping developers pipeline full
              > >
              > > I am looking for some good arguments to support this.
              > >
              > > Thanks
              > > Jack
              > >
              > >
              > >
              >
              >
              >
              > --
              > Bret Wortman
              > The Damascus Group
              > Fairfax, VA
              > http://bretwortman.com/
              > http://twitter.com/BretWortman
              >




              --
              Bret Wortman
              The Damascus Group
              Fairfax, VA

            • RonJeffries
              Hi Jack, ... Scrum has a clear and simple answer to this question. At the end of each Sprint, the team is jointly responsible for delivering a working,
              Message 6 of 9 , Nov 29, 2012
              • 0 Attachment
                Hi Jack,

                On Nov 28, 2012, at 12:15 PM, "JackM" <jack@...> wrote:

                I have some developers struggling with the dilema wrt completing stories in a sprint - i.e. meat your goal all crossing the goal line together vs keeping developers pipeline full

                Scrum has a clear and simple answer to this question. At the end of each Sprint, the team is jointly responsible for delivering a working, integrated, shippable increment of software, containing the Product Backlog items which they themselves selected, and forecasted that they could complete by the end of the Sprint.

                Once the team can do that reliably, then let's talk about keeping pipelines full, whatever the heck that is.

                Working software increment, every Sprint, containing what the team forecast they could do, in shippable order. How are you doing on that, so far?

                Ron Jeffries
                If it is more than you need, it is waste. -- Andy Seidl

              • RonJeffries
                Hi Jack, ... Tell us about your Product Owner and how they interact with the team. In particular, tell us how this senior developer finds himself interested
                Message 7 of 9 , Nov 29, 2012
                • 0 Attachment
                  Hi Jack,

                  On Nov 28, 2012, at 12:38 PM, "JackM" <jack@...> wrote:

                  So the discussion this senior developer had with me is he is worrying about his longer release commitments and getting that started so as to get ahead. 

                  Tell us about your Product Owner and how they interact with the team. In particular, tell us how this "senior developer" finds himself interested in or saddles with "longer release commitments". Scrum is one Sprint at a time. So these phrases are not working for me.

                  Ron Jeffries
                  If another does not intend offense, it is wrong for me to seek it;
                  if another does indeed intend offense, it is foolish for me to permit it.
                    -- Kelly Easterley

                • RonJeffries
                  Jack, ... If things are important, why are they not being done now? Why is the team working on unimportant things? Is the Product Owner stupidly selecting
                  Message 8 of 9 , Nov 29, 2012
                  • 0 Attachment
                    Jack,

                    On Nov 28, 2012, at 12:38 PM, "JackM" <jack@...> wrote:

                    The problem I see with this approach is the most important things get finished later rather than sooner. The whole swarming thing seems un-natural to them.

                    If things are important, why are they not being done now? Why is the team working on unimportant things? Is the Product Owner stupidly selecting unimportant things to do?

                    Ron Jeffries
                    www.XProgramming.com
                    Sometimes I give myself admirable advice, but I am incapable of taking it.
                    -- Mary Wortley Montagu



                  • Michael Vizdos
                    [minor high-jacking of the thread ON] Watching these types of conversations, I see the point that release planners and then Ron s passionate points from
                    Message 9 of 9 , Nov 29, 2012
                    • 0 Attachment
                      [minor high-jacking of the thread ON]

                      Watching these types of conversations, I see the point that "release planners" and then Ron's passionate points from almost the other side.

                      It is like watching people who speak two different languages try to have a conversation.

                      Or... even a person with a little knowledge of the language having a conversation with people who speak it fluently.

                      Or... the Shu-Ha-Ri concept (???).

                      Both are "right" from their different lenses and viewpoints that they bring to the table.

                      Something is missing from "an answer" when both "sides" come from the "I am right" standpoint (btw I am THERE A LOT personally too).

                      Observation... I'll continue listening watching and learning.

                      [minor high-jacking of the thread OFF]

                      - mike vizdos


                       
                      Thank you.

                      - mike vizdos
                         www.michaelvizdos.com/contact


                      On Thu, Nov 29, 2012 at 1:36 PM, RonJeffries <ronjeffries@...> wrote:
                       

                      Jack,


                      On Nov 28, 2012, at 12:38 PM, "JackM" <jack@...> wrote:

                      The problem I see with this approach is the most important things get finished later rather than sooner. The whole swarming thing seems un-natural to them.

                      If things are important, why are they not being done now? Why is the team working on unimportant things? Is the Product Owner stupidly selecting unimportant things to do?

                      Ron Jeffries
                      www.XProgramming.com
                      Sometimes I give myself admirable advice, but I am incapable of taking it.
                      -- Mary Wortley Montagu




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