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

intro and individualized sprint planning

Expand Messages
  • Philip Winston
    Just signed up to the list. My name is Philip Winston I live in Winchester, VA about a hour west of Washington DC. I m on a 5 person distributed team trying
    Message 1 of 5 , Mar 18, 2012
    View Source
    • 0 Attachment
      Just signed up to the list.  My name is Philip Winston I live in Winchester, VA about a hour west of Washington DC.  I'm on a 5 person distributed team trying to implement scrum.  We are in the 3d graphics / military simulation space.  We are on an existing project which has been around for a number of years.  For several years it was not agile at all, in the last year they instituted some elements of scrum and it was marginally successful.  I joined this year and we're trying to do scrum "for real" now for a number of reasons.

      I personally am new to scrum.  I've read some books and attended a one day course by Clinton Keith at GDC a few weeks ago.  But other than that I am green.

      I have a question.  For our first sprint planning meeting we kind of went around the room and each developer identified high priority tasks they could productively work on.  As in, developer A is mainly the Foo System person, so he picks off 10 days worth a Foo System tasks.  Now developer B is the Bar System guy, so we find 10 days worth of Bar System tasks.

      This seemed wrong, it didn't feel like we ever really had a sprint goal as a team, instead we were just loading up individuals with their own individual tasks.  With this method I feel like the team velocity isn't going to be that important.  Instead what we are likely to do is look at individual velocities, because that would guide us during the next round of planning.  If developer A averages 8 estimated days of work during the 10 day sprint, then load up 8 estimated days .  If developer B averages only 4 estimated days, no problem, give him 4 estimated days.  To each his own, just schedule everyone separately.

      My question is, is this individualized planning wrong?  If so how can we avoid it, given that developers really do have areas of expertise / specialization.

      -Philip

    • Alan Dayley
      Great question. You are correct, this type of individualized planning is not going to bring the expected benefits. It is not Scrum. The Sprint should be
      Message 2 of 5 , Mar 22, 2012
      View Source
      • 0 Attachment
        Great question.

        You are correct, this type of individualized planning is not going to bring the expected benefits.  It is not Scrum.

        The Sprint should be planned with Product Backlog Items features, stories or requirements that are described from the point of view of your customer or end user.  This keeps the focus on your customer's needs and helps the team work together.

        Your Product Owner should be shepherding the Product Backlog so the team has backlog items of this kind for planning.

        Alan

        On Sun, Mar 18, 2012 at 7:20 PM, Philip Winston <pwinston@...> wrote:
         

        Just signed up to the list.  My name is Philip Winston I live in Winchester, VA about a hour west of Washington DC.  I'm on a 5 person distributed team trying to implement scrum.  We are in the 3d graphics / military simulation space.  We are on an existing project which has been around for a number of years.  For several years it was not agile at all, in the last year they instituted some elements of scrum and it was marginally successful.  I joined this year and we're trying to do scrum "for real" now for a number of reasons.

        I personally am new to scrum.  I've read some books and attended a one day course by Clinton Keith at GDC a few weeks ago.  But other than that I am green.

        I have a question.  For our first sprint planning meeting we kind of went around the room and each developer identified high priority tasks they could productively work on.  As in, developer A is mainly the Foo System person, so he picks off 10 days worth a Foo System tasks.  Now developer B is the Bar System guy, so we find 10 days worth of Bar System tasks.

        This seemed wrong, it didn't feel like we ever really had a sprint goal as a team, instead we were just loading up individuals with their own individual tasks.  With this method I feel like the team velocity isn't going to be that important.  Instead what we are likely to do is look at individual velocities, because that would guide us during the next round of planning.  If developer A averages 8 estimated days of work during the 10 day sprint, then load up 8 estimated days .  If developer B averages only 4 estimated days, no problem, give him 4 estimated days.  To each his own, just schedule everyone separately.

        My question is, is this individualized planning wrong?  If so how can we avoid it, given that developers really do have areas of expertise / specialization.

        -Philip


      • Lukasz Szyrmer
        Phillip, Maybe the best way to get into the swing of things is to try swarming on tasks in order of business priority, so that everyone gets used to working
        Message 3 of 5 , Mar 23, 2012
        View Source
        • 0 Attachment
          Phillip,

          Maybe the best way to get into the swing of things is to try "swarming" on tasks in order of business priority, so that everyone gets used to working on both Foo and Bar systems. It will also help you establish the communication patterns that are important in scrum. While specialization can be a good thing, when it keeps you from understand what everyone else is doing it's definitely going to hurt your scrum implementation. While there may be a short term drop in productivity from getting used to doing this, having the perspective of a group of experts to discuss architecture and implementation as you go will eventually produce an architechture that is the best possible one for the problem you are trying to solve. Group "spiking" of potential solutions to a problem is another way of doing this.

          Luke


          Great question.

          You are correct, this type of individualized planning is not going to bring the expected benefits. It is not Scrum.

          The Sprint should be planned with Product Backlog Items features, stories or requirements that are described from the point of view of your customer or end user. This keeps the focus on your customer's needs and helps the team work together.

          Your Product Owner should be shepherding the Product Backlog so the team has backlog items of this kind for planning.

          Alan

          On Sun, Mar 18, 2012 at 7:20 PM, Philip Winston <pwinston@...<mailto:pwinston@...>> wrote:


          Just signed up to the list. My name is Philip Winston I live in Winchester, VA about a hour west of Washington DC. I'm on a 5 person distributed team trying to implement scrum. We are in the 3d graphics / military simulation space. We are on an existing project which has been around for a number of years. For several years it was not agile at all, in the last year they instituted some elements of scrum and it was marginally successful. I joined this year and we're trying to do scrum "for real" now for a number of reasons.

          I personally am new to scrum. I've read some books and attended a one day course by Clinton Keith at GDC a few weeks ago. But other than that I am green.

          I have a question. For our first sprint planning meeting we kind of went around the room and each developer identified high priority tasks they could productively work on. As in, developer A is mainly the Foo System person, so he picks off 10 days worth a Foo System tasks. Now developer B is the Bar System guy, so we find 10 days worth of Bar System tasks.

          This seemed wrong, it didn't feel like we ever really had a sprint goal as a team, instead we were just loading up individuals with their own individual tasks. With this method I feel like the team velocity isn't going to be that important. Instead what we are likely to do is look at individual velocities, because that would guide us during the next round of planning. If developer A averages 8 estimated days of work during the 10 day sprint, then load up 8 estimated days . If developer B averages only 4 estimated days, no problem, give him 4 estimated days. To each his own, just schedule everyone separately.

          My question is, is this individualized planning wrong? If so how can we avoid it, given that developers really do have areas of expertise / specialization.

          -Philip





          Linedata Limited
          Registered Office: 85 Gracechurch St., London, EC3V 0AA
          Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
        • Philip Winston
          Seems like the ideal scrum team is where everyone is a generalist. And the ideal scrum codebase is where anyone can hop in and work on any part of the code.
          Message 4 of 5 , Mar 23, 2012
          View Source
          • 0 Attachment
            Seems like the ideal scrum team is where everyone is a generalist.  And the ideal scrum codebase is where anyone can hop in and work on any part of the code.  Then you could pull stories off the Product Backlog without regard to who exactly will do them.  Look only at the team's velocity, pull that many points worth of stories, and then divide it up into tasks however.

            But this isn't common from my experience.  In teams I've been on there was always specialties, areas of the code best suited to one person or another.  For instance you might have a UI person and a database person and a math guru.  And you can't just swap around work between them, it would be inefficient to impossible for them to get their tasks done.  

            In that environment I don't see how to prevent sprint planning from becoming somewhat individualized.  That is if you are the database person, we can pull only 3 weeks worth of database tasks and they all go to you.  Does that make it automatically "not scrum" or are there shades of gray here, better or worse ways to incorporate individual capabilities while still making the sprint goal a team thing.  

            Thanks.

            -Philip



            On Thu, Mar 22, 2012 at 9:27 PM, Alan Dayley <alandd@...> wrote:
             

            Great question.


            You are correct, this type of individualized planning is not going to bring the expected benefits.  It is not Scrum.

            The Sprint should be planned with Product Backlog Items features, stories or requirements that are described from the point of view of your customer or end user.  This keeps the focus on your customer's needs and helps the team work together.

            Your Product Owner should be shepherding the Product Backlog so the team has backlog items of this kind for planning.

            Alan

            On Sun, Mar 18, 2012 at 7:20 PM, Philip Winston <pwinston@...> wrote:
             

            Just signed up to the list.  My name is Philip Winston I live in Winchester, VA about a hour west of Washington DC.  I'm on a 5 person distributed team trying to implement scrum.  We are in the 3d graphics / military simulation space.  We are on an existing project which has been around for a number of years.  For several years it was not agile at all, in the last year they instituted some elements of scrum and it was marginally successful.  I joined this year and we're trying to do scrum "for real" now for a number of reasons.

            I personally am new to scrum.  I've read some books and attended a one day course by Clinton Keith at GDC a few weeks ago.  But other than that I am green.

            I have a question.  For our first sprint planning meeting we kind of went around the room and each developer identified high priority tasks they could productively work on.  As in, developer A is mainly the Foo System person, so he picks off 10 days worth a Foo System tasks.  Now developer B is the Bar System guy, so we find 10 days worth of Bar System tasks.

            This seemed wrong, it didn't feel like we ever really had a sprint goal as a team, instead we were just loading up individuals with their own individual tasks.  With this method I feel like the team velocity isn't going to be that important.  Instead what we are likely to do is look at individual velocities, because that would guide us during the next round of planning.  If developer A averages 8 estimated days of work during the 10 day sprint, then load up 8 estimated days .  If developer B averages only 4 estimated days, no problem, give him 4 estimated days.  To each his own, just schedule everyone separately.

            My question is, is this individualized planning wrong?  If so how can we avoid it, given that developers really do have areas of expertise / specialization.

            -Philip



          • Michael James
            Yeah, I think you re right that Sprint Planning is not as simple as pulling in the same sized chunk as before. I hope no one s told you this is what Scrum
            Message 5 of 5 , Mar 25, 2012
            View Source
            • 0 Attachment
              Yeah, I think you're right that Sprint Planning is not as simple as pulling in the same sized chunk as before.  I hope no one's told you this is what Scrum requires; velocity isn't actually part of Scrum and no one I've worked with (including a couple math fiends) recommends using it that way.  If velocity is useful, it's mostly useful to help the Product Owner forecast.

              I also agree a UI designer, database expert, and math guru won't usually be able to do some of each other's tasks.  I write "some" here because when I ask people to think about how they actually spend most of their day it occurs to them 80% of their time is spent on things that didn't absolutely require their specialized training and knowledge.  (Usually 50% of it is stuff they might characterize as "bullshit," but that's another topic.)  There's an interesting case study from a guy named Arlo in Oregon whose team deliberately used the "least skilled implementor" for each task, driving them to learn from each other despite the short-term inefficiencies.  Teams that do pair programming have also tried frequent pair rotation to reduce pockets of specialized knowledge.

              The part most organizations underestimate (to the scale of trillions of dollars probably) is people's capacity to learn.  To me, an ideal Scrum team is one where everyone is interested in learning new things and builds this into their process of getting the old things done.  Without this, specialists become obsolete even within their specialty.  

              --mj


              On Mar 23, 2012, at 5:48 AM, Philip Winston <pwinston@...> wrote:

               

              Seems like the ideal scrum team is where everyone is a generalist.  And the ideal scrum codebase is where anyone can hop in and work on any part of the code.  Then you could pull stories off the Product Backlog without regard to who exactly will do them.  Look only at the team's velocity, pull that many points worth of stories, and then divide it up into tasks however.

              But this isn't common from my experience.  In teams I've been on there was always specialties, areas of the code best suited to one person or another.  For instance you might have a UI person and a database person and a math guru.  And you can't just swap around work between them, it would be inefficient to impossible for them to get their tasks done.  

              In that environment I don't see how to prevent sprint planning from becoming somewhat individualized.  That is if you are the database person, we can pull only 3 weeks worth of database tasks and they all go to you.  Does that make it automatically "not scrum" or are there shades of gray here, better or worse ways to incorporate individual capabilities while still making the sprint goal a team thing.  

              Thanks.

              -Philip



              On Thu, Mar 22, 2012 at 9:27 PM, Alan Dayley <alandd@...> wrote:
               

              Great question.


              You are correct, this type of individualized planning is not going to bring the expected benefits.  It is not Scrum.

              The Sprint should be planned with Product Backlog Items features, stories or requirements that are described from the point of view of your customer or end user.  This keeps the focus on your customer's needs and helps the team work together.

              Your Product Owner should be shepherding the Product Backlog so the team has backlog items of this kind for planning.

              Alan

              On Sun, Mar 18, 2012 at 7:20 PM, Philip Winston <pwinston@...> wrote:
               

              Just signed up to the list.  My name is Philip Winston I live in Winchester, VA about a hour west of Washington DC.  I'm on a 5 person distributed team trying to implement scrum.  We are in the 3d graphics / military simulation space.  We are on an existing project which has been around for a number of years.  For several years it was not agile at all, in the last year they instituted some elements of scrum and it was marginally successful.  I joined this year and we're trying to do scrum "for real" now for a number of reasons.

              I personally am new to scrum.  I've read some books and attended a one day course by Clinton Keith at GDC a few weeks ago.  But other than that I am green.

              I have a question.  For our first sprint planning meeting we kind of went around the room and each developer identified high priority tasks they could productively work on.  As in, developer A is mainly the Foo System person, so he picks off 10 days worth a Foo System tasks.  Now developer B is the Bar System guy, so we find 10 days worth of Bar System tasks.

              This seemed wrong, it didn't feel like we ever really had a sprint goal as a team, instead we were just loading up individuals with their own individual tasks.  With this method I feel like the team velocity isn't going to be that important.  Instead what we are likely to do is look at individual velocities, because that would guide us during the next round of planning.  If developer A averages 8 estimated days of work during the 10 day sprint, then load up 8 estimated days .  If developer B averages only 4 estimated days, no problem, give him 4 estimated days.  To each his own, just schedule everyone separately.

              My question is, is this individualized planning wrong?  If so how can we avoid it, given that developers really do have areas of expertise / specialization.

              -Philip



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