Slight contradiction in the Scrum Guide regarding the Backlog?

Last post 03:50 pm October 2, 2019
by Daniel Wilhite
21 replies
Author
Messages
03:49 pm January 13, 2017

Under the Product Backlog section, the second paragraph begins with:

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements.

Under the sub-section, Monitoring Progress Toward a Goal, the first paragraph contains:

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal.

This appears as a contradiction. What is the value of summing 'total remaining work' when you encouraging changing amounts of work? How do you define 'total remaining work' when the backlog 'is never complete'? Any thoughts?

The impact is probably minimal, except that my organisation struggles in coaching stakeholders on the importance of focusing on high-value features first and seeing the Backlog as a roadmap of value. Stakeholders in my organisation often still expect firm dates and try to impose deadlines in a traditional software development manner.

When the Scrum Guide says the total remaining work may be summed for assessment of 'progress towards completing projected work by the desired time' it becomes a more difficult point to argue.

05:12 pm January 13, 2017

> What is the value of summing 'total remaining work' when you
> encouraging changing amounts of work? How do you define 'total
> remaining work' when the backlog 'is never complete'?

Would you have no use for a forecast that consistently uses the best information available at the time?

09:01 am January 16, 2017

Posted By Ian Mitchell on 13 Jan 2017 05:12 PM
> What is the value of summing 'total remaining work' when you
> encouraging changing amounts of work? How do you define 'total
> remaining work' when the backlog 'is never complete'?

Would you have no use for a forecast that consistently uses the best information available at the time?

Forecast what? An amount of work that we are confident will change?

10:34 am January 16, 2017

The Sprint Backlog is the Development Team's forecast of the work they will do to meet the Sprint Goal. By improving that forecast based on the latest information, the Sprint Goal and its stakeholders can be better served.

There can be other goals, including ones articulated by the Product Owner in the Product Backlog, for which a similar forecast may prove useful. These can be inspected in a Sprint Review.

If there is no use for such goals then there may be little use, if any, for these forecasts and projective practices.

12:31 pm January 16, 2017

I understand the value of being able to forecast the work in the Sprint Backlog needed to meet the Sprint Goal, but based on the line "The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal", I think the discussion is not on the Sprint Backlog but the Product Backlog.

It seems potentially problematic to say the Product Backlog is never complete, continuously evolving, etc., to then say the Product Backlog should be able to sum 'total remaining work' for a stakeholders whose goal is complete all remaining work by a particular date.

12:32 pm January 16, 2017

Sorry, that should say "the Product Owner should be able to sum"...

03:49 pm January 16, 2017

What is the value of summing 'total remaining work' when you encouraging changing amounts of work? How do you define 'total remaining work' when the backlog 'is never complete'?

"At the moment" is the phrase to be read between the lines. Backlog is never complete because it would be an abuse to say that you can predict it's content in the future. But you can infer "total remaining work" from it's current shape.

04:40 pm January 16, 2017

Posted By Bartek Kobylecki on 16 Jan 2017 03:49 PM

What is the value of summing 'total remaining work' when you encouraging changing amounts of work? How do you define 'total remaining work' when the backlog 'is never complete'?

"At the moment" is the phrase to be read between the lines. Backlog is never complete because it would be an abuse to say that you can predict it's content in the future. But you can infer "total remaining work" from it's current shape.

My question remains, what is the value of inferring total remaining work when you are confident it will change?

05:06 pm January 16, 2017

what is the value of inferring total remaining work when you are confident it will change?

Transparency is the utmost value.

As you can't predict the extent of the change, then on the operational level it is a reasonable approach to know how much work is remaining. That helps to make informed decisions based on the current forecasts. For example PO might cancel the project or rearrange priorities.

05:46 pm January 16, 2017

That's right, it's the ability to make informed decisions which is valuable. The better the forecast, the better decision making can be.

07:34 am January 17, 2017

To be able to forecast all remaining work, all items on the backlog need to be estimated, in fact estimated is a requirement of a PBI. We are pretty (actually very) sure that as we learn more backlog items will change, new items will be added, others will be deleted and some will never be implemented. Then the question is, what value is there in estimating the entire backlog? It sounds very wasteful to me. I would only estimate the must-have (possibly should-have) features but according to the scrum guide any item on the backlog should be estimated.

05:00 pm January 17, 2017

What you could say is that as long as there is a product this product will have a backlog which is a plan and not report. What you could try is to explain your stakeholders they need to see that a User Story has a number of Story Points and with the known velocity you can forecast how many sprints it will take for said User Stories. As long as the product will be around there is bound to be a wishlists.

So what the product owner does is looking at the amount of work we told the stakeholders we where doing for example 50 story points and with a velocity of 10 points per Sprint said amount of work will be done after 5 (make it 6 if you factor in politics) sprints. If during a Sprint non functional requirements appear the PO has to add this to the work and make a call if this should be considered part of the agreed amount of work (adding it to the next sprint) just overlooked so far or if this is new requirement.

07:07 pm January 17, 2017

> ...the question is, what value is there in estimating the entire
> backlog? It sounds very wasteful to me.

It would only be wasteful if the time spent on it did not justify the value obtained. The correct application of Scrum should never mean introducing a wasteful practice, and there is no expectation that all estimates across the entire Product Backlog must be expressed with the same degree of confidence. If estimating the whole backlog would be of little use because of uncertainty and flux, then little time should be spent on it. However, it should be borne in mind that the process of estimation has value beyond the estimate itself; it can be instrumental in promoting refinement for example.

The Product Owner may find it advantageous to articulate certain goals in the Product Backlog. The forecast of work remaining until those goals are achieved could be of greater use, and the time invested in the estimation of relevant items may therefore reflect this.

11:49 pm January 19, 2017

Does it say anywhere that the "Goal" is necessarily the completion of the entire product backlog? Isn't it possible that the Product Owner sets intermediate goals that may align with tactical/strategic business objectives? For example, the first 20 product backlog items may constitute a Release 1.0 while the next 30 product backlog items may make up Release 2.0 (or Release 1.1). In that case, being able to estimate the progress towards that goal may be a very useful thing to have in order to promote visibility, transparency and to manage stakeholder expectations.

03:41 pm January 20, 2017

Posted By Swaroop Rao on 19 Jan 2017 11:49 PM
Does it say anywhere that the "Goal" is necessarily the completion of the entire product backlog? Isn't it possible that the Product Owner sets intermediate goals that may align with tactical/strategic business objectives? For example, the first 20 product backlog items may constitute a Release 1.0 while the next 30 product backlog items may make up Release 2.0 (or Release 1.1). In that case, being able to estimate the progress towards that goal may be a very useful thing to have in order to promote visibility, transparency and to manage stakeholder expectations.

That's true! I worry that in a difficult organisation, with difficult business people who are hesitant about applying Scrum in its entirety, claiming the entire Backlog as a 'Goal' could be used as a way to 'sneak in' a deadline.

But I think avoiding such difficulties is perfectly doable with the useful answers people have provided on here, including yourself.

12:48 pm March 29, 2018

If there is no use in calculating the work remaining, i.e. if this exercise is considered wasteful then such notion should be removed from the SCRUM guide. 

From the Scrum guide, "The Product Owner tracks this total work remaining at least every Sprint Review." 

I have a gut feeling I am wrong somewhere; but in the absence of a strong reasoning behind the above sentence from the Scrum guide, it only serves to create confusion. 

 

11:03 pm October 1, 2019

Unfortunately it is still unclear how this contradiction pointed by Alex and emphasized by Fredrik could be resolved. Is there a way to escalate to Scrum authors the issue with "At any point in time (including 1st Sprint) , the total work remaining to reach a goal <e.g. MVP > can be summed" contradicting  "The Product Backlog is dynamic; it constantly changes ".

This contradiction casts a cloud  of doubt over any discussion of using Burndown chart since at any reference I find, it  places the first point of Total (goal) points at Sprint 1 (so remaining work = total of all PBI-s to be competed to reach  goal (while spanning many sprints))

Ian @Ian-Mitchell, https://www.scrum.org/ian-mitchell 

what is the value in Dev team estimating PBI which PO dropped out and would never bring up again?

The "total work remaining" rule requires Dev team to estimate the whole Product Backlog during the 1st sprint or else  "At any point in time .." compliance would not be achieved. Considering that by definition, lower priority PBI-s are vague/not refined, estimation might take longer as discussion would be longer.

Therefore there must be some rules for estimating the whole Backlog allowing to achieve estimation within 10% of Dev team capacity and avoiding waste or, as Allen suggested, Scrum Guide has to be amended.

 

 

02:05 am October 2, 2019

At any point in time, the total work remaining to reach a goal can be summed.

@Yakov Simkin, The key point here is "to reach a goal". It doesn't say that it is the sum of all the work represented by all the PBI's in the Product Backlog. Even the section in the scrum guide reads "Monitoring Progress Toward Goals"

The "total work remaining" rule requires Dev team to estimate the whole Product Backlog during the 1st sprint or else  "At any point in time .." compliance would not be achieved. Considering that by definition, lower priority PBI-s are vague/not refined, estimation might take longer as discussion would be longer. - @Yakov Simkin

This appears as a contradiction. What is the value of summing 'total remaining work' when you encouraging changing amounts of work? How do you define 'total remaining work' when the backlog 'is never complete'? Any thoughts? - Alex Crosby

Then the question is, what value is there in estimating the entire backlog? - Fredrik Vestin

From the above passages, what I can infer is that, the assumption made (emphasized in bold) was that the total work constitutes the entire Product Backlog instead of specific goals.

Hope this clarifies things.

12:21 pm October 2, 2019

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review.

Putting on my Product Owner hat, I have no problem with this statement. I could very well sum the remaining work of the Product Backlog as a whole, though I probably wouldn't because I know it's emergent and will likely change. 

I may, however, add up the total work the team has identified to be completed in order to achieve a product goal I laid out (perhaps it's only 20 out of the 50 PBI's).

I would do this with the understanding that the number may change from Sprint to Sprint as we develop and learn more. It would still give insights into how we're progressing towards the goal and allow the team to have conversations about timelines, scope, etc.  

01:59 pm October 2, 2019

What is the value of summing 'total remaining work' when you encouraging changing amounts of work? How do you define 'total remaining work' when the backlog 'is never complete'? Any thoughts?

The 'total remaining work' keeps changing with time. That is why The Product Owner tracks this total work remaining at least every Sprint Review

I hope that answers your question.

03:00 pm October 2, 2019

In my opinion, this para must be read with the para 2 and para 4 of the Product Backlog section: 

A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.

And 

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

With the ever-changing product backlog, it is imperative that there are benchmarks and goals which reflect upon the requirements. It needs to be tracked to make sure that the work is in line (at least partially) with the requirements (including changes in business requirements, market conditions, or technology) of the customer/stakeholders. This tracking exercise or Guesstimate is also crucial for stakeholders to make provisions for resources including time. As PO is responsible for maximizing the value of the work Dev Team performs and making sure that PBI's are ordered well to reflect goals and missions, PO needs to understand the trends using the entire available PB at least once every sprint. 

 

03:50 pm October 2, 2019

Going to join in on the "towards a goal" theme and going to put a passage from the Scrum Guide section describing the Product Backlog that hasn't been shared yet. 

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. 

How would you be able to sum up work related to items low in the Product Backlog where the clarity is minimal?  Why would you even try?  Are you saying that everything in the Product Backlog is there for a single goal? Sure you could argue that the Product Backlog is only there to make the product better but is that a realistic goal to measure? That would be like trying to continually sum up your efforts to spend all the money you will ever make towards the goal of making your life better. But trying to sum up your progress towards the goal paying off the mortgage for your home is something that would be worthy of the effort.

Don't make the mistake of trying to take the words in the Scrum Guide verbatim.  There is an assumption of common sense being applied in the interpretations of the words.