Question (Developers say: Estimating PBIs and tasks are not needed for sprint planning...)

To answer this you should tell us what problem you feel needs to be solved with estimation?

If your Scrum Team has a done, useful and valuable Increment by the end of every Sprint, and they are also meeting their Sprint Goal, then perhaps there is nothing to do in this case.

If they are breaking work down during Product Backlog refinement to the "same size", where PBIs are ready for a Sprint and roughly the same size or PBIs are "right sized", meaning small enough to deliver during a Sprint where the Developers determine the right size, then perhaps they are indirectly estimating.

Forecasting doesn't always have to be done using velocity. Teams using flow metrics can leverage throughput and Monte Carlo forecasting in Sprint Planning. More about that can be read in the Scrum with Kanban resources on this site.

If none of the above is true, then someone needs to teach them about completing a Sprint Goal and having a done Increment by the end of the Sprint. And teach them the need to have "ready" PBIs. Having an estimate could help your Product Owner make tradeoffs as well (e.g. I have two PBIs of roughly the same value, but one is small, the other is large, let's do the smaller valuable PBI first).

Scrum does not require tasks to be estimated, that is a decision to be made by the Developers.

Thanks Chris,

The PBIs are not refined to the "same size". Considerations of this case are:

1- Without PBIs estimation, product owner may not be able to balance date or feature targets (e.g. meet the ship date)

2- Also, technical tasks with no size, would cause losing sprint backlog progress transparency (due to lack of updated burndown chart and absence of daily remaining...)

How are team members refining the work on the Product Backlog to "ready" if estimation is not being used, and how are forecasts being made?

What alternative forecasting techniques are being applied which do not involve estimation, and what role does "seniority" play in this?

It's true that Scrum does not require estimation. Previous iterations of the Scrum Guide have stated that Product Backlog Items have attributes, one of which is an "estimate". The 2020 revision of the Scrum Guide states that the attributes associated with Product Backlog Items vary with the domain and provide some examples of common attributes, one of which is size. The only requirement in the Scrum Guide related to estimating or sizing Product Backlog Items is that a Product Backlog Item that "can be Done by the Scrum Team within one Sprint" is "ready for selection in a Sprint Planning event".

Now, just because Scrum doesn't mandate estimates doesn't mean that there isn't a stakeholder who can benefit from having information about estimated time or effort to complete a Product Backlog Item. If the need exists, there should be a collaborative effort to understand exactly what the need is and what the best ways to satisfy it are. Someone telling the Scrum Team or the Developers to estimate Product Backlog Items is reducing the ability of the team to self-organize and self-manage.

If stakeholders are concerned with not be able to understand when work is likely to be finished or make tradeoffs between different orderings of the Product Backlog or not understand the current state of progress toward the Sprint Goal, these are the problems that should be presented to the team. Perhaps estimating Product Backlog Items is one solution to addressing these concerns, but there may be others. The whole Scrum Team should figure out what the best way is.

Thanks Ian and Thomas

I once led a few Scrum Teams and did not use sizing. I simply asked "how many of these refined PBIs can you fit into a one week Sprint (my preferred length). They would pick and get the work done. We were not obsessed with definitions of ready or done. We kept it simple. 

As far as long term forecasting for leaders is concerned, a good PO can estimate that and give leaders what they need for planning budgets and resources.

Thanks Mark

Hello,

As per my suggestion, we should follow some defined procedures in our organizations. and it is the responsibility of the Scrum Master to teach/coach/guide stakeholders for the best practice of scrum. So, the scrum master knows very well how to run sprint smoothly without this kind of hurdle. 

I'm working in one product-based MNC and we are 15 scrum masters and one agile coach. We are guiding to entire organization continuously and following best scrum practices based on empiricism.

So, we have defined PBR slot in each week for story point estimation. and in Sprint Planning we are guiding to developers about splitting stories into tasks, giving hours to tasks, regarding sprint goal, velocity etc.

Ex. If any developer is taking 40 hours for 1 task, then Scrum Master will guide them that tasks should be small otherwise there might be possibilities that some big tasks would remain pending for work items. In short, we guiding to them regarding verticle slicing also. 

So, please define the procedure and draft it into a "process document" and if you will go according to it then you will achieve rhythm/cadence for each sprint. 

Finally, I will not allow any story without estimation. 

Thanks Bhavin and thanks everyone.

I am thinking about your viewpoints and assaying them with the context. Also Ian questions and Thomas comments will help me to reveal this to develop team conflict resolution skills. 

1- Without PBIs estimation, product owner may not be able to balance date or feature targets (e.g. meet the ship date)

As @Chris Belknap suggested you should look at Monte Carlo analysis.  It allows forecasting based upon metrics like throughput, cycle time, Work In Progress.  This allows you to make forecasts based upon actual work instead of trying to do it based upon guesses (which is what an estimate is).  Find a copy of the book Actionable Agile Metrics for Predictability by Daniel S Vacanti.  It will help you better understand how you can measure and predict without using estimates. 

I have also worked with teams that did not use estimates.  They relied upon their pace or actual throughput to guide their planning.  In my opinion that is actually better than to use guesses. 

2- Also, technical tasks with no size, would cause losing sprint backlog progress transparency (due to lack of updated burndown chart and absence of daily remaining...)

If your Developers are using the Daily Scrum for the purpose of planning the day's work then how would the transparency be lost?  And as I alluded before, burning down guesses really doesn't provide true knowledge of the progress towards the goal. Since you mentioned daily remaining I'm going to guess that you are doing partial burndown of the estimates each day.  Which means that you are guessing how much of the original guess has been done. So your actual burndown is just a guess with a formula.  

Create your burndown chart to show the number of items in the Sprint Backlog and not the total of your guesses. Burndown the story as it is completed because that is the actual burndown of value being delivered.  That can help you determine your consistent throughput which will lead to better predictability in the long run.  Also by burning down actual items you can account for any technical debt incurred during the Sprint by creating an item in the Sprint Backlog if you really feel you need that.  In my experience the technical debt encountered while working on a Sprint Backlog Item will be accounted for by measuring actual item completion and be transparent because of the Daily Scrum. 

Thanks Daniel