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

RE: [scrumdevelopment] Re: Sprint planning

Expand Messages
  • Roy Morien
    Yes, it makes sense, but there are a number of different types of dependancy, and often the apparently dependant processes can be developed as if they are not
    Message 1 of 14 , Apr 30 12:28 AM
    • 0 Attachment
      Yes, it makes sense, but there are a number of different types of dependancy, and often the apparently dependant processes can be developed as if they are not dependant.

      For example, one type of dependancy is basically the scenario situation in a Use Case. In this situation the main processing scenario can be developed and left bare of the other scenarios, which can be added later, so they are not tightly coupled scenarios. Where the dependancy is such that one process  interfaces with another, and derives data from the oter, then you can break that dependancy and define an interface. You can then  create dummy processes that return sufficient data fro the main process to proceed, and plug in those other modules as they become available. An dependancy must be scrutinised to se if the coupling can be loosened.  One feature of a good User Story is that is is independant of other User Stories.

      The good old fashioned concepts of coupling and cohesion are as relevant and imortant today as they were 30 years ago when I first started writing COBOL programs.

      Regards,
      Roy Morien




      To: scrumdevelopment@yahoogroups.com
      From: tpagliocco@...
      Date: Wed, 30 Apr 2008 06:44:41 +0000
      Subject: [scrumdevelopment] Re: Sprint planning

      We run into a lot of stories that have dependencies into them. My
      first thought was to have the dependency be a separate story from the
      original story but what I learned was that incorporating the
      dependency into my story made for better use of time and completion.

      If story XYZ is #1 on your list and story ABC is a dependency on XYZ.
      Then in theory, story ABC is #1 because until ABC is done, you cannot
      move on to XyZ.

      Under the way we do it now, we make ABC a task under XYZ and if we
      have to spend the whole sprint on it, so be it, but we are attacking
      the backlog in correct prioritization order.

      Does that make sense or am i rambling from being tired heh.

      --- In scrumdevelopment@ yahoogroups. com, "Jeff" <ne14mx@...> wrote:
      >
      > Ahh.. the 'dependency' issue.
      >
      > I do beleive there are dependencies w/ backlog items that sometimes
      cant be
      > avoided.
      >
      > However, I also heard in the scrum training (which touched
      minimally on
      > software development) that most dependencies can almost always be
      removed.
      >
      > e.g. in your example...
      >
      > "Be able to edit account info" is fairly broad.
      >
      > The second one could be TWO backlog items...
      >
      > "be able to edit certain aspects (?) of an account's invoices, e.g.
      set the
      > "paid" flag, etc.
      >
      > "be able to edit account invoices on the account edit screen".
      >
      > My point is that by splitting up backlog items into finer
      granularity, where
      > each can meet a "doneness" criteria allows for better parallelism,
      and
      > improved decoupling of the code.
      >
      > Also, each backlog item can then be testable by itself.
      >
      > One thing I have seen, is that backlog "slicing" does
      require "architect
      > level" or at least fairly senior folks that have a good idea of
      what needs
      > to be built, and how to build it, to define backlog items
      sufficently,
      > before the team can commit to backlog items.
      >
      > Just my 2 cents. I'm new to this also.
      >
      >
      > _____
      >
      > From: scrumdevelopment@ yahoogroups. com
      > [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of Mark Smeltzer
      > Sent: Friday, March 03, 2006 10:03 AM
      > To: scrumdevelopment@ yahoogroups. com
      > Subject: [scrumdevelopment] Sprint planning
      >
      >
      > Speaking as one who is still very new to Scrum, I have a somewhat
      > newbieesque question to ask that has to do with Sprint planning.
      I've seen
      > in the literature that the highest priority items in the backlog
      should be
      > those that are most critical to the product's success and that the
      riskiest
      > of these items should be tackled first. I find that reasoning to be
      very
      > much in line with common sense.
      >
      > However, I am having troubles caching out what that means in
      practical
      > terms. Currently, we are assessing (on a scale of 1 to 10) the
      relative
      > effort, risk, and need factors of each item in the backlog, as well
      as
      > inter-item dependencies ( e.g. if story 1 = "be able to edit account
      > information" and story 2 = "be able to manipulate a list of the
      account's
      > invoices on the account edit screen", then story 2 is dependent
      upon story
      > 1), but it is unclear to me how those values and relationships
      should weigh
      > in the overall prioritization scheme.
      >
      > Any suggestions?
      >




      Grab it. You dream job is up for grabs.
    • tony pagliocco
      I see what you are saying about story criteria that is independant of other stories. I think where I misinterpret or am still learning about this process on
      Message 2 of 14 , Apr 30 9:27 AM
      • 0 Attachment
        I see what you are saying about story criteria that is independant of other stories.

        I think where I misinterpret or am still learning about this process on creating better user-centric stories is in what we define as dependencies.

        Most of oru dependicies for our projects are usually graphical assets.  To finish one story, we need the assets that come from the design dept.

        So we either a) make the design of the assets its own story, or we make it a task under our main story which is the project that requires the assets.

        In this case, where grahpics are what are needed to finish the product and that asset comes from a different dept , what are your thoughts on proper story creation then ?



        Roy Morien <roymorien@...> wrote:
        Yes, it makes sense, but there are a number of different types of dependancy, and often the apparently dependant processes can be developed as if they are not dependant.

        For example, one type of dependancy is basically the scenario situation in a Use Case. In this situation the main processing scenario can be developed and left bare of the other scenarios, which can be added later, so they are not tightly coupled scenarios. Where the dependancy is such that one process  interfaces with another, and derives data from the oter, then you can break that dependancy and define an interface. You can then  create dummy processes that return sufficient data fro the main process to proceed, and plug in those other modules as they become available. An dependancy must be scrutinised to se if the coupling can be loosened.  One feature of a good User Story is that is is independant of other User Stories.

        The good old fashioned concepts of coupling and cohesion are as relevant and imortant today as they were 30 years ago when I first started writing COBOL programs.

        Regards,
        Roy Morien




        To: scrumdevelopment@ yahoogroups. com
        From: tpagliocco@yahoo. com
        Date: Wed, 30 Apr 2008 06:44:41 +0000
        Subject: [scrumdevelopment] Re: Sprint planning

        We run into a lot of stories that have dependencies into them. My
        first thought was to have the dependency be a separate story from the
        original story but what I learned was that incorporating the
        dependency into my story made for better use of time and completion.

        If story XYZ is #1 on your list and story ABC is a dependency on XYZ.
        Then in theory, story ABC is #1 because until ABC is done, you cannot
        move on to XyZ.

        Under the way we do it now, we make ABC a task under XYZ and if we
        have to spend the whole sprint on it, so be it, but we are attacking
        the backlog in correct prioritization order.

        Does that make sense or am i rambling from being tired heh.

        --- In scrumdevelopment@ yahoogroups. com, "Jeff" <ne14mx@...> wrote:
        >
        > Ahh.. the 'dependency' issue.
        >
        > I do beleive there are dependencies w/ backlog items that sometimes
        cant be
        > avoided.
        >
        > However, I also heard in the scrum training (which touched
        minimally on
        > software development) that most dependencies can almost always be
        removed.
        >
        > e.g. in your example...
        >
        > "Be able to edit account info" is fairly broad.
        >
        > The second one could be TWO backlog items...
        >
        > "be able to edit certain aspects (?) of an account's invoices, e.g.
        set the
        > "paid" flag, etc.
        >
        > "be able to edit account invoices on the account edit screen".
        >
        > My point is that by splitting up backlog items into finer
        granularity, where
        > each can meet a "doneness" criteria allows for better parallelism,
        and
        > improved decoupling of the code.
        >
        > Also, each backlog item can then be testable by itself.
        >
        > One thing I have seen, is that backlog "slicing" does
        require "architect
        > level" or at least fairly senior folks that have a good idea of
        what needs
        > to be built, and how to build it, to define backlog items
        sufficently,
        > before the team can commit to backlog items.
        >
        > Just my 2 cents. I'm new to this also.
        >
        >
        > _____
        >
        > From: scrumdevelopment@ yahoogroups. com
        > [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of Mark Smeltzer
        > Sent: Friday, March 03, 2006 10:03 AM
        > To: scrumdevelopment@ yahoogroups. com
        > Subject: [scrumdevelopment] Sprint planning
        >
        >
        > Speaking as one who is still very new to Scrum, I have a somewhat
        > newbieesque question to ask that has to do with Sprint planning.
        I've seen
        > in the literature that the highest priority items in the backlog
        should be
        > those that are most critical to the product's success and that the
        riskiest
        > of these items should be tackled first. I find that reasoning to be
        very
        > much in line with common sense.
        >
        > However, I am having troubles caching out what that means in
        practical
        > terms. Currently, we are assessing (on a scale of 1 to 10) the
        relative
        > effort, risk, and need factors of each item in the backlog, as well
        as
        > inter-item dependencies ( e.g. if story 1 = "be able to edit account
        > information" and story 2 = "be able to manipulate a list of the
        account's
        > invoices on the account edit screen", then story 2 is dependent
        upon story
        > 1), but it is unclear to me how those values and relationships
        should weigh
        > in the overall prioritization scheme.
        >
        > Any suggestions?
        >




        Grab it. You dream job is up for grabs.



        Tony Pagliocco
        Development Manager
        SheKnows.Com

        View Tony Pagliocco's profile on LinkedIn


        Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

      • Sharmila D
        I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have
        Message 3 of 14 , Nov 23, 2009
        • 0 Attachment
          I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.

          Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.

          Has anyone encountered this kind of situation?

          How do we improve the sprint planning in this case?

          We have also proposed competency building but the "expert" area will still remain to some extent.

          It's easier to write "the team commits and picks of work" but that's not really the case here.

          Any thoughts or ideas?
        • Gabriel Notari
          Hi Sharmila, One thing we try to do on the company I work on is to do not concentrate all work on one particular area or subject within the same person. Since
          Message 4 of 14 , Nov 23, 2009
          • 0 Attachment
            Hi Sharmila,

            One thing we try to do on the company I work on is to do not concentrate all work on one particular area or subject within the same person. Since all individuals are from the same team, we try to spread the knowledge across the team by associating tasks from different subjects to different people. This gives you in short-term a decrease of productivity of course, since people needs to ramp-up on new areas or technologies and this will be reflected somehow (even in product quality, since unexperienced people usually generates more bugs). However, in the mid/long-term this gives the team the benefit of being able to associate tasks in a more flexible manner and this problem tends to disappear. Also, this reduces your risk of being "hostage" (I really dislike this term, but I c)

            On Tue, Nov 24, 2009 at 1:13 AM, Sharmila D <sharmila.patwardhan@...> wrote:
             

            I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.

            Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.

            Has anyone encountered this kind of situation?

            How do we improve the sprint planning in this case?

            We have also proposed competency building but the "expert" area will still remain to some extent.

            It's easier to write "the team commits and picks of work" but that's not really the case here.

            Any thoughts or ideas?


          • Gabriel Notari
            Now with the full answer. Sorry for duplicates. Hi Sharmila, One thing we try to do on the company I work on is to do not concentrate all work on one
            Message 5 of 14 , Nov 23, 2009
            • 0 Attachment
              Now with the full answer. Sorry for duplicates.

              Hi Sharmila,

              One thing we try to do on the company I work on is to do not concentrate all work on one particular area or subject within the same person. Since all individuals are from the same team, we try to spread the knowledge across the team by associating tasks from different subjects to different people. This gives you in short-term a decrease of productivity of course, since people needs to ramp-up on new areas or technologies and this will be reflected somehow (even in product quality, since unexperienced people usually generates more bugs). However, in the mid/long-term this gives the team the benefit of being able to associate tasks in a more flexible manner and this problem tends to disappear. Also, this reduces your risk of being "hostage" (I really dislike this term, but I can't find a better one) of a single member, so if he/she became sick, or resigns the position, you have someone who can do the work inside the team. Not sure if this is the answer you were looking for, but it is working on the teams I'm working on.

              Thanks,
              Gabriel

              On Tue, Nov 24, 2009 at 1:59 AM, Gabriel Notari <manobill@...> wrote:
              Hi Sharmila,

              One thing we try to do on the company I work on is to do not concentrate all work on one particular area or subject within the same person. Since all individuals are from the same team, we try to spread the knowledge across the team by associating tasks from different subjects to different people. This gives you in short-term a decrease of productivity of course, since people needs to ramp-up on new areas or technologies and this will be reflected somehow (even in product quality, since unexperienced people usually generates more bugs). However, in the mid/long-term this gives the team the benefit of being able to associate tasks in a more flexible manner and this problem tends to disappear. Also, this reduces your risk of being "hostage" (I really dislike this term, but I c)


              On Tue, Nov 24, 2009 at 1:13 AM, Sharmila D <sharmila.patwardhan@...> wrote:
               

              I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.

              Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.

              Has anyone encountered this kind of situation?

              How do we improve the sprint planning in this case?

              We have also proposed competency building but the "expert" area will still remain to some extent.

              It's easier to write "the team commits and picks of work" but that's not really the case here.

              Any thoughts or ideas?



            • JackM
              there s a couple things you can do. 1. try take advantage of pair programming which will help you in the long run as this tends to cross-pollinate knowledge ..
              Message 6 of 14 , Nov 24, 2009
              • 0 Attachment
                there's a couple things you can do.

                1. try take advantage of pair programming which will help you in the long run as this tends to cross-pollinate knowledge .. then you'll have fewer silos in the long term.

                2. After you plan you say you end up with uneven workload. Well that's not all that bad assuming that all can get done that you planned into the sprint. If someone is loaded beyond their capacity well then you only have one option and that is to pull some stuff off.

                If some folks have filler time, then they could pair program with the other loaded developers, they can help write unit tests etc, trust me there's always plenty to go around.

                Further to your questions, absolutely, many times after a planning sessions you figure out that there's too much stuff. In this case you negotiate with the PO what to drop

                Hope this helps
                Jack
                www.agilebuddy.com
                blog.agilebuddy.com
                twitter.com/agilebuddy

                --- In scrumdevelopment@yahoogroups.com, "Sharmila D" <sharmila.patwardhan@...> wrote:
                >
                > I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.
                >
                > Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.
                >
                > Has anyone encountered this kind of situation?
                >
                > How do we improve the sprint planning in this case?
                >
                > We have also proposed competency building but the "expert" area will still remain to some extent.
                >
                > It's easier to write "the team commits and picks of work" but that's not really the case here.
                >
                > Any thoughts or ideas?
                >
              • Mark Levison
                Your problem isn t sprint planning, its the silos. Anytime you have silos - i.e. only person that can do something you will have bottlenecks. Whole books are
                Message 7 of 14 , Nov 25, 2009
                • 0 Attachment
                  Your problem isn't sprint planning, its the silos. Anytime you have silos - i.e. only person that can do something you will have bottlenecks. Whole books are written on this subject (think Goldratt and the Theory of Constraints). Scrum tells you to have team members pull + self assign work - only when they're free to avoid this problem. Over time it will create a team of generalising specialists.

                  Congratulations this is one of the key agile problems that everyone finds sooner or later.

                  Cheers
                  Mark Levison

                  Blog | Twitter | Office: (613) 761-9821


                  On Mon, Nov 23, 2009 at 10:13 PM, Sharmila D <sharmila.patwardhan@...> wrote:
                   

                  I have been working with a Scrum team for the core Architecture of the product. We have been working in sprints. However since it is core architecture, we have different modules for which within the team we have people who have expertise. So after we have planned and estimated in the sprint planning meeting, we often end-up with uneven leveling of work.

                  Although I completely understand that in the Sprint planning, the team commits. However after the sprint planning we have to work out and find if we have people who are overloaded.

                  Has anyone encountered this kind of situation?

                  How do we improve the sprint planning in this case?

                  We have also proposed competency building but the "expert" area will still remain to some extent.

                  It's easier to write "the team commits and picks of work" but that's not really the case here.

                  Any thoughts or ideas?



                  Blog | Twitter | Office: (613) 761-9821
                Your message has been successfully submitted and would be delivered to recipients shortly.