Product Backlog Refinement

Is refinement achieving what you want it to?

For instance, do the Development Team able to come out of every Sprint Planning, confident that they can it complete the most important Product Backlog Items done within the Sprint? Are Sprint Goals consistently being achieved, and are the Development Team providing accurate enough forecasts during Sprint Planning?

Does Sprint Planning feel like a low-stress, pleasant way to start a Sprint, and does it feel like an efficient use of time?

Is the Product Owner able to re-prioritize items on the Product Backlog, based on the estimates that are provided by the Development Team? 

Do the Development Team consistently build what was wanted, and do they avoid wasting time on building unwanted functionality?

If the answer to all of those questions is yes, then there is a good chance that refinement is working fine. If not, then it is worth considering whether refinement can be improved.

We recently discussed estimates based on complexity in a previous thread on this forum: https://www.scrum.org/forum/scrum-forum/17825/having-trouble-story-poin…

When estimating stories, we only consider the risks, unknowns and complexity of the story but we don't really consider the effort to deliver that stories since it is part of the "how" (tasks) which will only be done during sprint planning.

Is the Development Team also considering:

- the Definition of Done, and the level of quality which must be attained during development in order to have an increment of release standard

- the estimates given to stories in the past, and whether or not they have proven fit for Sprint capacity planning

"During this activity, we inspect stories, ask clarifications and come up with acceptance criteria. Also, we give story points to each of the refined stories.

When estimating stories, we only consider the risks, unknowns and complexity of the story but we don't really consider the effort to deliver that stories since it is part of the "how" (tasks) which will only be done during sprint planning."

Refinement process sounds pretty fine to me, however I don't really understand why effort isn't the driving force behind the estimation. The way I've been practising and coaching is to have effort as main indicator of numbers (whether you use F scale or any other scale).

Estimation is a planning metric to help the Scrum team understand what can be achieved in a given sprint. Whereas the sprint planning how-part should cover the steps necessary to achieve the sprint goal, by creating a plan (temporary, for it can/will be ammended later) of tasks/activities required... So during the how-part you shouldn't really estimate (re-estimate) stories.

When estimating stories, we only consider the risks, unknowns and complexity of the story but we don't really consider the effort to deliver that stories 

How do you differentiate complexity from effort?