impacts of not estimating

How would the team be able to set an achievable sprint goal to commit to if they have no insights in what it can deliver within a sprint length? Let alone, if by some guessing a goal can be crafted, how can the team assess what and how much work it should plan to meet this goal?

And during the sprint, how can one assess progress? Daily and towards the sprint goal? And how would the team inspect and adapt to where is can improve if it is unclear what can be achieved?

How is the team able to forecast and develop towards a Done increment at the end of the sprint, if it is unable to see how much work is left for it to be Done?



Outside the team, What would happen to transparency if you were not estimating? How would team and PO be able to plan? How can be transparent how much work is "undone", in other words, how much work is still left to develop on product level? How would product vision be impacted? How can the organization plan or see the market?



in general we can sum it up by asking: Since empiricism is the basis of Scrum, How can empiricism be served if it is unknown how much work has been done and is to do?  How can you inspect and adapt something unknown?



I can think of a milion more questions to ask ;)

Most times the conversations we have when estimating, rather than the estimate itself, provides the most value. Estimates do not have to be in story points either. T short sizes, right sizing or same sizing may be used. Encourage the Dev Team to experiment and find out what works for them.

Have you asked your Scrum Team how estimates do or don't help them? Some ways estimates may help:

• An estimate of a PBI helps the product Owner make tradeoffs. The Product Owner has two PBIs with roughly the same value, but one PBI may take 2 hours, the other may take 2 weeks. Let's order the 2 hour PBI higher.
• The estimate can help answer stakeholder questions about "When will it be done?" or "How much will be done by a certain date.
• As mentioned above, an estimate may help the Dev Team decide on capacity during Sprint Planning. 

Scrum, as lightweight as it is, does require an estimate for a Product Backlog item (PBI). If you are asking whether or not a task of a PBI is needed, well no, estimating a task is optional as is the need to even have a task.

I don't see any issues with not estimating.

The purpose of estimating is to help the team during Sprint Planning. Coming out of the Sprint Planning session, the team needs to have an appropriate Sprint Goal that is likely to be met within the Sprint timebox. The team also needs to select a total number of Product Backlog Items for the Sprint that make sense based on the team's capacity to do the work. The Scrum Guide doesn't say how to estimate, but reading between the lines, you can understand what the intended use of the estimate is.

As long as the team is able to look at Product Backlog Items, select Product Backlog Items that are likely to be completed within a Sprint, and craft a Sprint Goal that is likely to be met in a Sprint, the estimation can be done through any means. The team can decompose the work into roughly equal-sized units of work. The team can estimate in ideal hours. The team can estimate in story points. The team can choose to not formally estimate. As long as the goals and objectives of Sprint Planning and any stakeholder needs are supported, it doesn't matter how the team estimates.

What it means to be likely to meet a Sprint Goal or complete a set of Product Backlog Items depends on the organizational context. Some organizations or some stakeholders are more or less tolerant of risks related to schedule and dates of completion of work. The tolerance for risk may drive if an estimate is necessary and what methods of estimation are used.

If your team is looking at the items in the Product Backlog and pulling some of those items into a Sprint Backlog with the common understanding that those items can be done in a Sprint, then the team is estimating.  Estimating can occur in any way that the team feels is useful and beneficial. It does not have to be a method that involves putting some kind of indicator on a item.  

Well, then how do we know our velocity?  Good question and thank you for asking. 

Velocity can be measured in a lot of ways and it is my opinion that using a series of guesses to measure your velocity is the worst way to do it.  Velocity is just the rate at which something moves. It has nothing to do with how well the team is able to guess. Looking at metrics such as cycle time or throughput can measure velocity.  There are many ways to measure velocity.

The Scrum Guide is intentionally vague about estimation and velocity because there are so many ways of accomplishing both. 

what would be the impact in terms of not getting benefits from scrum by not estimating?

How important do you think it is for a development process to be predictable? Might estimation have a part to play in that, when work is complex with significant unknowns?