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

Re: [scrumdevelopment] Product Backlog syncing with Sprint Backog

Expand Messages
  • Graeme Matthew
    More to the point, any two teams tasked with the same work will estimate that same backlog of work you would never have 2 teams estimating or doing the same
    Message 1 of 6 , Oct 6, 2005
    • 0 Attachment
      "More to the point, any two
      teams tasked with the same work will estimate that same backlog of work "

      you would never have 2 teams estimating or doing the same piece of work that
      is "replication" so it doesnt really matter, whoever is doing it estimates
      it whether the estimate is correct or a guess (which most are) does it
      matter the measurement is still in the hours estimated irrespective,

      hope i make sense .....


      cheers


      Graeme
      ----- Original Message -----
      From: "Christian Edward Gruber" <cgruber@...>
      To: <scrumdevelopment@yahoogroups.com>
      Sent: Thursday, October 06, 2005 11:07 AM
      Subject: Re: [scrumdevelopment] Product Backlog syncing with Sprint Backog


      > Technically, there is no "Earned Value" in scrum, there is only "work
      > left to perform". Put another way, we burn down, not burn up. There
      > are varying opinions on this, but the two main reasons I've seen for
      > this, is a) the team is only concerned with what's ahead, and b) earned
      > value starts to try to evaluate estimation based on some objective
      > standard, which is impossible.
      >
      > Issue b) is certainly contrary to PMBOK wisdom, but it comes down to this:
      > Hours, as measured in Agile estimation processes do not track to real
      > hours. They reflect "ideal hours" or "touch time" or some other
      > psychological abstraction. Real hours are often inflated by a factor of
      > 3, but even that can't be reliably done. More to the point, any two
      > teams tasked with the same work will estimate that same backlog of work
      > differently. Therefore, the purpose of such estimation is to determine,
      > after a few iterations, what the capacity, or velocity of the team is.
      > The estimates of the team are therefore only valid against future work
      > of THAT team, and bear no relationship that can be reliably decomposed,
      > with any objective standard.
      >
      > This flies in the face of much estimation theory in the PMI community,
      > which tries to "scientifically manage" these processes. However, Scrum
      > is an empirical process, not a defined one. It discovers reality. That
      > discovery is why the Sprint backlog contains substantially more work
      > than the product backlog. We discover work as the project progresses.
      >
      > Anyway, it's not a complete answer, but might give you a start at the
      > different assumptions that Scrum makes.
      >
      > regards,
      > Christian.
      >
      > blues_alchemy wrote:
      >
      >> I'm fairly new to SCRUM mamangement, but absolutely bought in, so I
      >> have many questions. The question that I'm initially struggling with
      >> right now is how the HOURS in the Product Log reconciles with the
      >> Sprint Log. As I understand it, the Burn Chart seems to be based
      >> off of the Product log.
      >> My confucion stems from the fact that the product log is the
      >> initial base estimation to "plan" a sprint. The sprint log actually
      >> will contain the tasks in the product backlog planned for the sprint
      >> as well as more tasks. (Therefore more hours). So the sprint log and
      >> release hours on the product log will be different.
      >> Is the idea to go back to the Product Log and increase it's base
      >> estimates on a daily basis?
      >>
      >> I will have to admit that I am initially from the PMI world of
      >> performing Earn Value analysis where baselining is imperative.
      >>
      >> Any help to set me straight is greatly appreciated. (Then on to my
      >> next topic of upfront analysis and estimating for fixed cost
      >> projects!!)
      >>
      >> Bill
      >
      >
      >
      > --
      > -----------------------------------------------------------------------
      > Christian E. Gruber President, Israfil Consulting Services Corp.
      > (905) 640-1119 (office) cgruber@...
      > (416) 998-6023 (cell) http://www.israfil.net
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > --
      > No virus found in this incoming message.
      > Checked by AVG Anti-Virus.
      > Version: 7.0.344 / Virus Database: 267.11.10/120 - Release Date: 5/10/2005
      >
      >
    • Schiel James - SHS Malvern
      Let me try a slightly different perspective on your question, Bill. When an item on the product backlog has an estimate, it has probably been placed there
      Message 2 of 6 , Oct 14, 2005
      • 0 Attachment
        Let me try a slightly different perspective on your question, Bill.
         
        When an item on the product backlog has an estimate, it has probably been placed there either due to the efforts of one or more Scrum teams doing some early ("pre-sprint") analysis on backlog items or, as seems to happen in some cases, the estimate was derived by one or more individuals/architects/analysts knowledgable enough in the product to make a high-level guess. This high-level guess is good enough for some basic release planning and prioritization (to the extent that prioritization should be driven primarily by ROI), but it remains just that -- a high-level guess. Even if the item itself gets some more attention in pre-sprint analysis and becomes a little more defined, it remains nothing more than a "budgeted" cost for a feature.
         
        Once the item is assigned to a Scrum team, you should expect that, through the course of the sprint planning meeting, that the item will be broken down into smaller items and into smaller tasks such that a new, more precise estimate can be determined. What you have now is a "budgeted" amount (from the high-level estimate done pre-sprint) and a new estimated cost. If the new estimate is less than the budgeted amount, you really don't have a problem. You can adjust the product backlog accordingly if you like or simply let the sprint finish and remove the item from the product backlog. If the new estimate is slightly more than the budgeted amount, you're probably still OK and can either correct the product backlog or let it go.
         
        However, if the new estimate is considerably more than the budgeted amount (and YOU have to decide how much "considerably more" is), you need to go back to the Product Owner and let them know that the feature that was supposed to, for example, cost 20 days of effort is now estimated to cost 50 days of effort. It's possible that the product owner will be OK with this. It's more likely that the product owner will (after raving about the initial estimate), suggest cutting aspects of the feature down to reduce the cost. The PO may even drop the feature entirely, willing to buy it at 20 days effort, but unwilling to buy it at 50 days effort. The important thing is that the PO needs to know that the feature cost went up -- the PO needs to decide if the feature is still wanted at that price.
         
        So, my short answer for you is that reconciliation between the product backlog estimate and the sprint backlog estimate occurs with the product owner. They are responsible for maximizing the return on investment of your product and need to understand what they're buying and for how much.
         
        Jim Schiel
        CSM Trainer
        Siemens Medical Solution Health Services


        From: blues_alchemy [mailto:wingersoll@...]
        Sent: Wednesday, October 05, 2005 4:46 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Product Backlog syncing with Sprint Backog

        I'm fairly new to SCRUM mamangement, but absolutely bought in, so I
        have many questions. The question that I'm initially struggling with
        right now is how the HOURS in the Product Log reconciles with the
        Sprint Log.  As I understand it, the Burn Chart seems to be based
        off of the Product log. 
        My confucion stems from the fact that the product log is the
        initial  base estimation to "plan" a sprint. The sprint log actually
        will contain the tasks in the product backlog planned for the sprint
        as well as more tasks. (Therefore more hours). So the sprint log and
        release hours on the product log will be different.
        Is the idea to go back to the Product Log and increase it's base
        estimates on a daily basis?

        I will have to admit that I am initially from the PMI world of
        performing Earn Value analysis where baselining is imperative.

        Any help to set me straight is greatly appreciated. (Then on to my
        next topic of upfront analysis and estimating for fixed cost
        projects!!)

        Bill





        -------------------------------------------------------------------------------
        This message and any included attachments are from Siemens Medical Solutions
        USA, Inc. and are intended only for the addressee(s).
        The information contained herein may include trade secrets or privileged or
        otherwise confidential information. Unauthorized review, forwarding, printing,
        copying, distributing, or using such information is strictly prohibited and may
        be unlawful. If you received this message in error, or have reason to believe
        you are not authorized to receive it, please promptly delete this message and
        notify the sender by e-mail with a copy to Central.SecurityOffice@...

        Thank you
      • Ron Jeffries
        ... Yes ... and yet, as I understand the fundamental notion of Scrum, the team is supposed to /commit/ to the Sprint Goal. That means something in the range of
        Message 3 of 6 , Oct 14, 2005
        • 0 Attachment
          On Friday, October 14, 2005, at 10:13:58 AM, Schiel James - SHS Malvern wrote:

          > Once the item is assigned to a Scrum team, you should expect that, through
          > the course of the sprint planning meeting, that the item will be broken down
          > into smaller items and into smaller tasks such that a new, more precise
          > estimate can be determined. What you have now is a "budgeted" amount (from
          > the high-level estimate done pre-sprint) and a new estimated cost. If the
          > new estimate is less than the budgeted amount, you really don't have a
          > problem. You can adjust the product backlog accordingly if you like or
          > simply let the sprint finish and remove the item from the product backlog.
          > If the new estimate is slightly more than the budgeted amount, you're
          > probably still OK and can either correct the product backlog or let it go.
          >
          > However, if the new estimate is considerably more than the budgeted amount
          > (and YOU have to decide how much "considerably more" is), you need to go
          > back to the Product Owner and let them know that the feature that was
          > supposed to, for example, cost 20 days of effort is now estimated to cost 50
          > days of effort. It's possible that the product owner will be OK with this.
          > It's more likely that the product owner will (after raving about the initial
          > estimate), suggest cutting aspects of the feature down to reduce the cost.
          > The PO may even drop the feature entirely, willing to buy it at 20 days
          > effort, but unwilling to buy it at 50 days effort. The important thing is
          > that the PO needs to know that the feature cost went up -- the PO needs to
          > decide if the feature is still wanted at that price.

          Yes ... and yet, as I understand the fundamental notion of Scrum,
          the team is supposed to /commit/ to the Sprint Goal. That means
          something in the range of "get it done come hell or high water".

          Now getting it done shouldn't mean "work 800 hours", nor should it
          mean "do fast but shoddy work." However, when the tasks add up to a
          lot more than the estimate, there is another possibility than just
          "the estimate was wrong, sorry."

          There is quite often, I find, another way to deliver the goal that
          the product owner has. Perhaps the GUI can be simplified a bit.
          Perhaps the developers had a particularly baroque way of
          manipulating the database in mind. Perhaps they were going to build
          more "framework" than was strictly needed.

          I see this sort of thing happening very frequently in teams that
          break down features into technical tasks, and then divide up the
          technical tasks along technical skill lines. That approach
          /inevitably/ makes things take longer than they need to, and I
          really do mean inevitably.

          Let me explain. No, there is too much. Let me sum up.

          We have some user-facing feature to build, and we have, in our
          minds, broken out several technical tasks which our design sense
          tells us will add up to that feature. Then we "go parallel" to do
          them.

          For each technical task, there are three possibilities:

          1. We will do just the right amount of work on it and get it just
          right. This only happens in fairy tales.

          2. We will do too little work on it and when we integrate, we'll
          have to do more. This often happens; it slows us down and creates
          rework.

          3. We will do more work on it than is needed, and it will
          integrate just fine. But we will have done too much work.

          So the chance is vanishingly small that we'll do the right amount of
          work, and the only stable state is that we do too much. The result
          is that every task-oriented breakdown of a feature requires more
          work than is strictly necessary. It's an unavoidable result of
          breaking things down that way.

          One might think that the effect wouldn't be that great, but in
          practice I find that it very often is. One fix is to do stories
          "vertically" rather than breaking the tasks out among different
          programmers. Another is to do very tiny sub-stories first, to
          minimize the amount of overwork.


          So ... there is another alternative when the price looks too high.
          Maybe the price is wrong and there's a better way to meet the need.
          A team's ability to please its customer goes up sharply when they
          learn to work with that focus.

          Ron Jeffries
          www.XProgramming.com
          You can observe a lot by watching. --Yogi Berra
        • Schiel James - SHS Malvern
          Ron, I agree with you, and, as you said, there s too much to detail out in an email.... With my teams, I encourage the pre-sprint analysis work to break user
          Message 4 of 6 , Oct 14, 2005
          • 0 Attachment
            Ron, I agree with you, and, as you said, there's too much to detail out in an email....
             
            With my teams, I encourage the pre-sprint analysis work to break user stories (or other feature packages) down into small items that can be completed in a few days by a few people. This gives us the ability to go to the product owner and not simply say "Oops!  It's too big," but rather, we can say things like, "The whole thing is bigger than we thought, but there are slices we can remove that will allow us to complete the work in the sprint and you (the PO) can make a decision about the rest later."
             
            This approach is absolutely necessary if you want to avoid saying "Oops!  It's too big -- sorry," because Ron, your expectation of the team's commitment is correct. Scrum teams have a lot of freedom, but arbitrarily dumping problems like this into the PO's lap for a solution isn't one of them. Just like it's the PO's job to maximize ROI, it is the practicing Scrum Master's responsibility, and the Scrum teams', to maximize agility.
             
            Jim


            From: Ron Jeffries [mailto:ronjeffries@...]
            Sent: Friday, October 14, 2005 10:42 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Product Backlog syncing with Sprint Backog

            On Friday, October 14, 2005, at 10:13:58 AM, Schiel James - SHS Malvern wrote:

            > Once the item is assigned to a Scrum team, you should
            expect that, through
            > the course of the sprint planning meeting, that the
            item will be broken down
            > into smaller items and into smaller tasks such
            that a new, more precise
            > estimate can be determined. What you have now
            is a "budgeted" amount (from
            > the high-level estimate done pre-sprint)
            and a new estimated cost. If the
            > new estimate is less than the budgeted
            amount, you really don't have a
            > problem. You can adjust the product
            backlog accordingly if you like or
            > simply let the sprint finish and
            remove the item from the product backlog.
            > If the new estimate is
            slightly more than the budgeted amount, you're
            > probably still OK and can
            either correct the product backlog or let it go.

            > However,
            if the new estimate is considerably more than the budgeted amount
            > (and
            YOU have to decide how much "considerably more" is), you need to go
            > back
            to the Product Owner and let them know that the feature that was
            >
            supposed to, for example, cost 20 days of effort is now estimated to cost 50
            > days of effort. It's possible that the product owner will be OK with
            this.
            > It's more likely that the product owner will (after raving about
            the initial
            > estimate), suggest cutting aspects of the feature down to
            reduce the cost.
            > The PO may even drop the feature entirely, willing to
            buy it at 20 days
            > effort, but unwilling to buy it at 50 days effort. The
            important thing is
            > that the PO needs to know that the feature cost went
            up -- the PO needs to
            > decide if the feature is still wanted at that
            price.

            Yes ... and yet, as I understand the fundamental notion of Scrum,
            the team is supposed to /commit/ to the Sprint Goal. That means
            something in the range of "get it done come hell or high water".

            Now getting it done shouldn't mean "work 800 hours", nor should it
            mean "do fast but shoddy work." However, when the tasks add up to a
            lot more than the estimate, there is another possibility than just
            "the estimate was wrong, sorry."

            There is quite often, I find, another way to deliver the goal that
            the product owner has. Perhaps the GUI can be simplified a bit.
            Perhaps the developers had a particularly baroque way of
            manipulating the database in mind. Perhaps they were going to build
            more "framework" than was strictly needed.

            I see this sort of thing happening very frequently in teams that
            break down features into technical tasks, and then divide up the
            technical tasks along technical skill lines. That approach
            /inevitably/ makes things take longer than they need to, and I
            really do mean inevitably.

            Let me explain. No, there is too much. Let me sum up.

            We have some user-facing feature to build, and we have, in our
            minds, broken out several technical tasks which our design sense
            tells us will add up to that feature. Then we "go parallel" to do
            them.

            For each technical task, there are three possibilities:

              1. We will do just the right amount of work on it and get it just
              right. This only happens in fairy tales.

              2. We will do too little work on it and when we integrate, we'll
              have to do more. This often happens; it slows us down and creates
              rework.

              3. We will do more work on it than is needed, and it will
              integrate just fine. But we will have done too much work.

            So the chance is vanishingly small that we'll do the right amount of
            work, and the only stable state is that we do too much. The result
            is that every task-oriented breakdown of a feature requires more
            work than is strictly necessary. It's an unavoidable result of
            breaking things down that way.

            One might think that the effect wouldn't be that great, but in
            practice I find that it very often is. One fix is to do stories
            "vertically" rather than breaking the tasks out among different
            programmers. Another is to do very tiny sub-stories first, to
            minimize the amount of overwork.


            So ... there is another alternative when the price looks too high.
            Maybe the price is wrong and there's a better way to meet the need.
            A team's ability to please its customer goes up sharply when they
            learn to work with that focus.

            Ron Jeffries
            www.XProgramming.com
            You can observe a lot by watching. --Yogi Berra

            -------------------------------------------------------------------------------
            This message and any included attachments are from Siemens Medical Solutions
            USA, Inc. and are intended only for the addressee(s).
            The information contained herein may include trade secrets or privileged or
            otherwise confidential information. Unauthorized review, forwarding, printing,
            copying, distributing, or using such information is strictly prohibited and may
            be unlawful. If you received this message in error, or have reason to believe
            you are not authorized to receive it, please promptly delete this message and
            notify the sender by e-mail with a copy to Central.SecurityOffice@...

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