Chronological dependencies of estimations

The Scrum Guide says:

"The Product Backlog is an emergent, ordered list of what is needed to improve the product."

Product Backlog Refinement is an ongoing activity for handling this emergence. Hence the Developers ought to know the order in which Product Backlog items are currently forecast for delivery, irrespective of how close or far away they may be from implementation.

• They may choose to implement any common logic with the first user story that requires it.
• Alternatively, they may implement that logic ahead of time: Scrum doesn't say anything about Product Backlog items having to be user stories at all.

They should also consider the quality implications of this new work, and enhance the Definition of Done accordingly.

There's two aspects to this question.

The first part is about decomposing and estimating dependent work. I've seen two approaches to this that have worked out well. In one approach, the dependent work is part of both Product Backlog Items and both are estimated as if they need this dependent work. In the other approach, the dependent work is pulled out into its own Product Backlog Item, estimated, and then the dependent work is estimated as if the first piece of work is done and this dependency is tracked. I've found that the latter approach is better when the dependent work can be done (designed, implemented, integrated, tested, and perhaps even delivered) on its own while the former approach is better if you need one of the Product Backlog Items to make it valuable. At the end of the day, I'd leave it up to the team to determine which approach to use and it would likely be on a case-by-case basis rather than a standard rule.

The second part is about estimating work that isn't "close to implementation". In my experience, this is often wasteful. Estimating work would be part of refinement, so the real question is how much of the Product Backlog should be refined and ready to work on. This does depend on context. Environments that have a high amount of instability in the Product Backlog should probably have less of the Product Backlog refined at once time while more stable environments can estimate more of the Product Backlog. Regardless, I wouldn't have more than 2 or 3 Sprints worth of work (as measured by count of Product Backlog Items, Story Points, person-hours, or whatever your unit of measurement is) in a well-refined and ready for selection state. Until the work is something that would be done in the next 2 or 3 Sprints, there's often no need to spend too much time refining it, including putting an estimate on it, since the details will likely change based on the team's growing knowledge and changes to the team's way of working.

Agree with Ian and Thomas.

Break into 3 units -

1. Common logic (if this can be split, split it)

2. Story A

3. Story B

Estimate roughly during decomposition, and near implementation, estimate stories using story points with consent of all Scrum team.

Dont rush towards completing of all 3 above mentioned units in single sprint, this can be implemented during course of one release cycle, in multiple sprints.

Thank you for your quick and detailed replies. 

It seems like my definition of a Backlog Item was simply wrong. I thought that it should always deliver direct value to the customer so that they can prioritize it. But if I understand you correctly, a Backlog can contain technical Items in addition to the actual User Stories. 

This totally makes sense and even loosens a knot I had in my brain. I always wondered how you can wrap every single thing to do in a Backlog Item with direct value for the customer.

A little sidenote: so far I did not practice Scrum. All I know about it is the theory I remember from my time in university. Currently I am trying to bring some structure into the so called "Backlog" we have in the company I work for. Since my memory seems to have faded over time, I guess I should refresh it before I continue. :)

The Product Backlog is an emergent, ordered list of what is needed to improve the product.

The items in the Product Backlog do not need to directly deliver value to the customer. Value is delivered through the Increment. However, it can be useful for Product Backlog Items to be expressed in a manner that allows key stakeholders to understand the work represented by the Product Backlog Item and why it's important. Technical work can often be presented in a way that lets these stakeholders understand it. Because they understand the value of the work and the dependencies between various items in the Product Backlog, the stakeholders can have informed discussions with the Product Owner about the ordering of the work in the Product Backlog.