Mike,
as you say, the items “further down the slope” are not as well understood, which implies that, through grooming the PBL, they will be better explained/described/specified/understood as then rise towards the top. Do you reflect this by assigning a high Story Point value at first, a value which can be reduced as the User Story becomes better understood?

Story Points, as I understand, are intended to reflect a User Story’s complexity, size, and uncertainty. And items not well understood, have a high degree of uncertainty and therefore a high Story Point value (“higher risk factor leads to higher estimate” is true for all techniques of estimation).

The Story Point value will be reduced as the team’s understanding increases, and re-estimated (or even, split the User Story into two or more new User Stories as the product and PBL evolves) when developers feel the estimate is no longer correct.

Question is, how far down the product backlog is it useful to assign Story Point values to the User Stories? (OK, I know the answer to this one - “It depends”:) ) The more stories that are estimated, the better the basis for release planning will be. However, if the User Stories are so poorly understood that the estimate is pure guesswork, it has little or no value and thus shouldn’t be done - “eliminate waste”.

Hi Ådne—
As always, thanks for contributing to the discussion here. We all appreciate it.

I would never want to say that I put a higher number of story points on a user story simply because of where it resides on the product backlog. However, user stories that are further off into the future should be larger stories because we’re not going to do them for awhile. That will indeed mean they are likely to have larger estimates. But it’s not *because* they are further out. It’s because they haven’t been thought about much yet. (Which also means, as you say, they are likely to have more uncertainty around them.)

(I need to blog here sometime when I can about what a story point really is. It is most assuredly an estimate of how long it will take. Complexity and uncertainty can be factors but the estimate is of the effort to complete the user story.)

I don’t know if I can do much better than your own “it depends” on the how far down to assign story points question. In some companies and projects, it is important to have a really good plan. That means estimating further into the product backlog. It also means that those more distant items cannot be left as great big user stories (because an error in a huge one could be catastrophic for a plan). In other companies, this isn’t necessary at all. 

And yes, if the estimate has no value, don’t estimate. Estimating on its own can be considered wasted. If the estimate leads to better decisions, it’s not wasteful.

Unfortunately it is “it depends”.  I’ve had that re-enforced again through a project I’m just coming off of on which I served as Scrum Master.  We had items in the PBL that are well understood and estimated but now reside down further down the slope because there wasn’t a clear understanding of the cost of an item vs. its value the to business / customer until they were investigated / estimated more thoroughly. 

Another factor in this project was a change in product strategy.  This change took items that were toward the top of the PBL at the beginning of the project and pushed them almost out of the release.

IMO a “DEEP” PBL provides a Scrum Team one of it’s best tools for enabling it to ensure it delivers the highest value possible, especially in the face of change.

Hi Mike—
Your story is a great example of why we want a lightweight initial estimating approach (I like story points). This allows us to discover the need to adjust priorities.

And yes, almost everything ends up in an “it depends” answer, doesn’t it? ;)

As much as estimating low-priority product backlog items can be challenging, working with coarse-grained items supports the continuous discovery of the product’s functionality. I think of low-priority items as placeholders for more detailed functionality to be discovered later on.

I find that if a team cannot size an item, it usually pays to investigate why. Is it because the team does not understand what the item means? Or is it because the team is unsure how to implement the item? Both can indicate that there is risk involved in delivering the item. If that’s the case, decompose the item so that the team can implement a small piece of the functionality thereby addressing the risk.

Hi Roman—
Thanks for joining the discussion. I know you cover these ideas more in your upcoming book and it will be great to have that available in a few months.

Thank you all for your comments, I find them really helpful.

As I wrote in a comment on the “How Do You Get from Here to Agile? Iterate.” post, we’ve established a “Scrum Process Backlog”, and (not surprisingly) the first item relates to estimating and the PBL.  So, my questions above are the questions and associations that rose to the top of my mind when I read the blog post.

(a side note: I just love how this blog addresses the very issues I find we need to address when implementing Scrum!)

Mike - here’s how I’ve tried to explain Story Points: It can be broken down into three components - “Risk” (or uncertainty), which of course you want to reduce as much as possible (the “D” in DEEP will reduce risk). Second part is “Complexity”, which can be understood as the amount of analysis/design you need to do. The last one is “Size”, which reflect the amount of deliverables to be produced. (Every programming task requires some analysis of the problem, and some design of the code, before being coded - and this fits well with AMDD, where each iteration (sprint) contains some modeling.) But overall, it should reflect how much time we expect to spend on the User Story.

Roman - recently, one of our teams (we have 2) estimated a PBI to 20 story points, but failed to pinpoint more than ca 1/3 of the hours normally estimated for a 20-point PBI, yet the team felt 20 story points was justified. The PBI was committed to the Sprint, and the Sprint did not meet its commitment. Next sprint ends tomorrow, and looks like commitment will be met. So, lesson learned for the team.

—-

I can see how a DEEP product backlog will really help us deliver. The problem is getting the business side to understand it as well. Good thing I’m attending a CSPO-course soon, will probably help :)

Hi,
I’ve translated your interesting post in french : “Rendre le Product Backlog DEEP”
Regards, Fabrice

The sister rule could be, make the Stories INVEST.

When is a good time to estimate stories in the product backlog.  I have read that it is best to have this completed prior to the sprint planning meetings.

Hi Philip—
That topic is addressed in the blog post called “When Should We Estimate the Product Backlog”. Mike