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

Product Backlog syncing with Sprint Backog

Expand Messages
  • blues_alchemy
    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
    Message 1 of 6 , Oct 5, 2005
    • 0 Attachment
      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 Edward Gruber
      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
      Message 2 of 6 , Oct 5, 2005
      • 0 Attachment
        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
      • 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 3 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 4 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 5 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 6 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.