What vs How and when to work on each?

Are the Developers taking the Definition of Done into account when estimating the work?

Yes. Acceptance criteria met, potentially releasable increment, etc.

I'm beginning to think of this as an issue in defining Ready and what Ready means to the team. What should be done before Ready and what should be done after? If we need to do a lot of problem solving before getting to ready, then do we have a poor understanding of Ready? And, I don't want to be telling the team how to do their jobs.

Any good articles on this topic? Happy to hear recomendations.

I don't think it's reasonable to avoid all of the "how" when decomposing or estimating Product Backlog Items. In fact, getting into some level of how the work will be done may reveal new ways of splitting it up in ways to get feedback earlier. It's about defining the right level of how the work will be done. Some amount of up-front design that lets the team ensure they understand the work, split the work into the right pieces, and estimate the work is totally appropriate.

I'd also consider up-front design a de-risking strategy. If you defer all of the design to the Sprint in which the work is anticipated to be done, then you may end up with work that can't be done within a Sprint. It takes practice, but finding that sweet spot to balance early design to support de-risking and estimation with avoiding waste by deferring some design decisions can go a long way.

I'm not sure how you conduct Product Backlog Refinement sessions, but something that I'd also look at is giving the Developers a chance to go through refinement on their own. Having a whole-team (including the Product Owner) session is very valuable for making sure that the team understands the state of the Product Backlog and what work needs to be refined, but I've found that the vast majority of effective refinement happens when the Developers (as individuals, in pairs, or in small groups) work through the work and involve the Product Owner when necessary to validate their understanding. That said, I have also worked with teams that did prefer to spend the majority of refinement time as a team, so your mileage may vary.

This is the second paragraph in the Scrum Guide's section on the Product Backlog.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Notice that there is no mention about how much work needs to be done before an item is "deemed ready for selection in a Sprint Planning event".  From what you say, it appears to me that the team feels there should be some level of refinement on the technical implementation.  

In my experience, I have seen VERY FEW Product Backlog items created that were immediately ready to be pulled into a Sprint Backlog.  There has always been a need for refinement of the problem. What you refer to as a "planning PBI" would be what I have always referred to as refinement.  However, we have never included them as items in the Product Backlog unless it was what most refer to as a Spike.  These items are to allow a short exploration of technical details in order to further understand the work that will need to take place. They are timeboxed and limited to 1-2 people so that they do not become a major factor in a Sprint.  Any of the work done is considered throw-away, however sometimes portions of the work will be kept and used in the solution.

Your expectation that an item created in the Product Backlog will be immediately ready to be addressed is unrealistic.  You have to allow time for the item to be understood and made ready to be addressed in a Sprint.  The Sprint Backlog is made up of Product Backlogs that are ready to be addressed.  The Product Backlog is made up of any work needed to improve the product.  The items in the Product Backlog will exist in different stages of refinement. 

Thanks for the comments.

Thomas - I like "I'd also consider up-front design a de-risking strategy." This is what the team is communicating and we are trying to work it into our process. I'm thinking we really need more time in our PBR.

@Daniel - thanks for your comments. "Your expectation that an item created in the Product Backlog will be immediately ready to be addressed is unrealistic. " I don't think this to be the case - maybe I need some refinement here ;-)

I've come to think of the Ready point as being a useful marker point. Not as a gate, but to consider what work is done either side of that point. What is really sprint work and what is refinement work. As pointed out, there is not a lot of guidance in the scrum guide. Researching various books and blog posts on the topic, it is also ambiguous and vague.

What is really sprint work and what is refinement work. As pointed out, there is not a lot of guidance in the scrum guide. 

Refinement work is done for each and every PBI, refinement have its session, its a good practice to maintain DEEP product backlog.

PB refinement have 2 major part -

1. Breaking down the items, for this consider INVEST criteria , below flowchart might give a better insight into user story splitting

http://1qtspv2a8qad3nf2xr3pzat3-wpengine.netdna-ssl.com/wp-content/uplo…

2. Estimating PB item - this has various techniques which includes prioritization of PB item - Bucket sizing, T-shirt sizing, planning Poker 

Once the refinement of PB item is done, it can be considered as a candidate for sprint backlog.

Definition of Ready will be a helpful checklist for dev team to consider a PB item for development. 

DoR will be helpful to build the product right.

Acceptance criteria can be helpful to build the right product.

In Scrum, distinguishing between what and how is crucial. While Product Backlog Refinement primarily focuses on defining what needs to be done, addressing how during this phase can enhance clarity and effectiveness. However, it's essential to strike a balance. Lengthening PBR sessions to delve into the how can be beneficial, enabling a deeper understanding and more accurate estimation. Yet, excessive detail may hinder flexibility and creativity during implementation. Collaboratively finding the right balance ensures efficient planning and successful delivery within your team's context.