The beauty of estimation in Scrum

All Scrum partictitioners (may they be developers, scrum masters or product owners) know that the Agile Scrum framework itself doesn't require or use the concept of estimation. This shouldn't be surprising as in iterative work one chooses only items that might be delivered at the end of an iteration. The inherent answer to the question of 'when will this be done?' is 'on the completion of the sprint in which this item was selected into'.

But in the real world customers do demand to know things like "when will the project be done?", "when will a certain feature be delivered?" and so on.

I will not dig into why the guesswork required by classical project management is wrong. Instead I will describe one way in which Scrum can serve to provide this kind of information.

First of all, Scrum is an empirical method. You don't look at something and guess. You measure, you compare, you record and then use basic math (or statistics if you're into that) to calculate forecasts.

So first point is to not use time. Even if the customer wants to know dates or hours, providing this information isn't a developer's task. As a developer, you are required to choose your work and do it. The choosing part may require you to size work in order to be able to compare. Sizing work doesn't have standards since it's inherently subjective and it depends on the technology used, project type, chosen measurement baseline and even developer experience. In other words, it's particular to a project. You can name this arbitrary unit as you please (some use "story points" but that can misleading since not all backlog items are user stories) but the mandatory step is to define your baseline for comparisons.

Once you get this going, you're going to start sizing the work. You will size work that goes into a sprint, complete the sprint and then see how much work was done and how much wasn't done. You will do this several times and check to see how it varies between sprints. Once the variantion has lowered significantly and your team seems to have found a common understanding of your arbitrary unit, you can say you've found a velocity.

The velocity represent that basic concept of work done over time. What is different in Scrum is that this value isn't something you guess, it's something you have measured over time and reprents the work that your team does on your project in the known conditions that surround you anad your client. It's as particular as it gets and it represents reliable information collected from the actual progress of the project.

Having this information at hand, the team can take it to the next level and proactively size backlog tasks in advance.

Those the use estimation in Scrum call this something on the lines of "backlog refinement" where they take a peek into the future and check the incoming work.

Now comes the part about using basic math: you know the size of the work and you know the quantity of work you can do per sprint. Diving the latter by the former will give you an estimation for completion based on observed work.

For example, in Scrum you have a backlog of 100 items, valued at 500 units of work. Your team does 20 units of work per sprint, meaning that hte backlog will be done under the current known conditions in 500/20 = 25 sprints. If your enterprise charges their client per sprint, you can provide this information and you're done.

If not, you can add your own conversion: a sprint can be 2 weeks to that means 50 weeks of work. One week has 5 working days, so that means 250 working days. A working day has 8 hours so that means 2000 worked hours. Your team has 6 members (4 devs, 1sm, 1po) so that means 12000 billable hours (if you bill by the hours).

As work gets added or removed, the calculation will change in real time. Every sprint you will have an accurate image of what is left to do.

Compare that will the flow of classic guesswork. You start by guessing 12000 hours. Your team works and logs time. Since the correlation between time and done work isn't that reliable, your only metric is the time left which in reality doesn't reflect the actual work left. Overshot tasks need to be reanalyzed which means that there will be a debt of analysis work accumulating for the sole purpose of informing the client. This work will also take time, resulting in greater discrepancies between consumed time and initial guess.

On the client's side, reliance on the difference between time guessed and time logged means that the window to take action in case something goes wrong grows smaller as the remaining time gets smaller.

Scrum method: based on the actual conditions of the project, offers real-time information, grows more accurate as time passes.