Originally published @ hashnode.
Heredia, Costa Rica, 2022-11-05

Many of us have had the experience of being asked: "After reading the user story, how many points do you think are fair for it?" Typical question in a sprint planning meeting or backlog grooming session.

So how can you answer? This is not a simple thing by any means, and I have never, ever been in a team that gives you any guidelines or tools that help you answer this question.

What are Story Points?

Story points are a numeric measure of the amount of work required by a user story. They are commonly defined as 6 hours of work, and 6 hours of work is usually defined as 1 working day. The usual 2 hours missing from this time definition are purposedly removed to account for meetings, trainings and any other non-programming effort.

So How To Estimate Story Points?

There are many guides out there that provide principles and best practices. I absolutely love this one because it is so mathematical. Mathematics is always a beatiful thing.

But let's be honest, we won't sit down to do this math on every user story. I personally apply the line counting method, described next. It does have math, but it is a very simple math that can be done mentally.

The Line-Count Method

This is my main method: Locate instances where the work needs to be done by scanning the source code for relevant keywords. For this I use Notepad++ and its great Find In Files function.

To give you a practical sense of this method, let's pose an example user story. Imagine a C# project, either monolithic or microservices:

Replace all console logging with structured logging using Serilog.

Excellent choice (Serilog) for structured logging. How many points?

Well, if the user story doesn't say, I, as a structured logging connoisseur, know that I need more information. At least I must know the expected sinks. I ask the question and the team lead tells me: Just worry about the console sink for now.

Great! That makes my estimation super easy. Setting up additional Serilog sinks would require extra time, but if it is just the console sink, the set up time is neglible. Let's do some Find In Files.

Line-Counting Process

1. Make sure you have a copy of all relevant source code in your PC.
2. Start Notepad++ and search for Console.Write. Make sure it is pointed at the root folder where the relevant source code is.
3. Make sure you only target files whose file extension is .cs.
4. Search!
5. Take note of the total search result count. On a medium sized project, you'll probably see hundreds.
6. Now estimate in your head the amount of time it takes to change a single line: "Assuming I have the logger object in place, just rewriting the Console.WriteLine statement takes 1 minute. Let's add an extra minute to ensure proper selection of the severity (debug, info, warning, etc.). So 2 minutes times the total number of hits."
7. But look, you made an assumption. That assumption needs backing up, so we are not done. Notepad++ also gave you the total number of hit files. Being the connoisseur that I am, I know I need to prepare a logger object in every one of those files, so think some more: "Need to inject the ILogger<T> object through the constructor, declare the class level property or field and assign it. So 3 minutes per file."
8. Add up the total time. Say, 270 hits in 55 files. $270*2+55*3=705 minutes=11.75 hours$

Basically 12 hours, or 2 6-hour days, or 2 story points, final answer.

Additional Considerations

Do account for unknowns. If you are tasked with unfamiliar work, it is best if somebody else does the estimation. If you are forced into estimating, add at least one story point to account for the unknown/research time.

Flaws?

There are, yes. The most horrendous one is when developers remove code by commenting it instead of deleting. If block comments are used, you won't notice that your hit results in Notepad++ include commented code!! This is probably the main reason why I hate deleting code by commenting it.

Do you have a favorite story point estimation method? Share!