Ask HN: How to estimate my stories properly and not let them overflow

Consider song writing. You have a framework in mind, and a pretty good idea of the end goal. You know from the start if it's a ballad or a stadium rocker. But rarely does a song writer sit down and steadily write a song from beginning to end.

There are inspired periods. There are tired periods. Starts and fits. Amazing stuff comes out, but there wasn't a straight and narrow path taken to get to it.

Developing and coding are really similar that way. Some coders may be particularly capricious. But even they aren't robots.

Checklists work well to make sure you’ve accounted for everything you know will usually come up but often get forgotten. These are things like the code cleanup and refactoring.

You should try to go quite granular rather than broad when coming up with your estimates. Better to have lots of small tasks, it shows you’ve put enough thought into the estimate and you have enough small tasks that estimation errors will average out.

You should also consider the level of detail the requirements have. For example if you don’t have wireframes there’s a lot more uncertainty than if you do. You should put confidence intervals or buffers to account for that.

It’s always better to overestimate than underestimate. There’s an asymmetry here where underestimating can cause chaos and overestimating is much less painful.

I recommend reading Software Estimation by Steve McConnell.

Your estimates should be way higher with the legacy codebase. Science says 1.7x what you first expect. I'd pad that to 2.5x if not higher. If you can do it in 1 day, estimate 3 days for it. If you have 1 day to do it, get it done in 2 hours.

There's a lot of literature around estimates and most of them encourage data. Which is a poor approach for this case because of your points 1 and 3. It's helpful to compute, but take into account that the data is off by a lot.

I'm still skeptical about the whole Fibonacci thing like why but that's my opinion.

For our team we story point things together after discussing the task and asking questions.

About the scope thing... Mention it or at least do the actual main story first then clean it up if you have time. There is always the code review part to get feedback on how to write it better.

Beauty may also be personal bias.

I'm sorry, I'm whether experienced developer neither a programmer. I hope besides mine, you'll get right answers to your question :)

It looks like there is no proper lead / project management in that. I, too, tend to overperfectize my work. Me, too, struggle to be on time. And, too, sometimes I work like superhero and on other days I'm like a zero.

At first, I've identified the parts and events of a workday that cost me time without me being productive.

No. 1 Timekiller "smoking and coffee". On a typical 8h workday I smoke like 10 cigs.. every cig I need about 5min. So I lose approx 1h daily.

No. 2 Timekiller "emails, talks". This does distract you from the "flow". You again have to find into what you've been up to.. but then, it's time for a cig again.

This might be your problem too.

There are a lot of microdistractions around us. Like hearing music while working ("oh.. I don't like this song, let's search the one I like..." WASTED!)

Or getting notifications, adjusting the volume.. or, too, google an answer for the problem isn't the problem by itself, if you get your answer instantly. But if you have to read a ton of comments to get your problem solving answer, you probably have already lost some other ideas out of scope.

So, one have to identify this small microdistractions and be aware that anything you do besides reading, understanding, directly rewriting parts of code, is a time consuming distraction.

So the best is to minimize breathing :)

You can't absolutely and effectively minimize distractions, as, being aware that something is a distraction and trying to minimize it, you invest some thoughts & time on that - what in fact is a distraction by itself :)

I came up with a strategy to handle that:

- know it & accept it

- quantify the needed time for the tasks. Like smoking a cig approx. 5 mins, writing answer emails 5 mins, drinking coffee 2 mins. .. and so on. Every Microtask is viewed in bigger context and so is the time spent.

By that you get the feeling for the daily work's time flow. It's all just about the time awareness.

The next part of my strategy handling that:

- make up a "house" in your mind with a few rooms.

Sounds strange, but this is how our brain works. We think in "boxes"/"rooms"/"spaces". Try it by yourself:

Sometimes, you want to do something, stand up, go there - when you're there, suddenly you can't remember what you wanted to do anymore. Have you experience this once or twice?

... Just go back into the room/place where you came up with the idea you forgot, and It will strike you again :)

So, analogue to this brain workings, I made up a house in my mind with dynamic rooming for ideas & problems i work on in one room, drinking coffee in the other - by actively switching the body & mind to the respective rooms, when doing the respective tasks.

By that I can separate distractions from the actual problem-solving. By that I can imaginary lockup my working room and being in a state of pure concentration - actively minimizing all distractions that are in the other brain rooms :)

I needed quite some time to incorporate this into my thinking - I think the most time needed, was to realize where the problems are and to do the abstraction to the room level :)

.. this is my productivity booster method. It doesn't account to creativity, though.

For creativity, one needs chaos - pure chaos! With ideas buggling around like worms (yes, ideas, they're longish, not roundish like flies, so they're not flying around xD)

For that I have developed a different method: - filter

But that's quite difficult to explain and would touch the database max capacity.

Creativity is completely different from structured.

If you need to code and refactor at the same time, you mix creativity with plain, I call it, "translation" of old legacy code. This both things are opponents as the second requires pure 1-to-1 work, while the first, explosions of ideas, playing, mixing, deleting... Which is a distraction by the definition.

You'll need a playroom for that :)

Every playroom is usually equipped with games & plays, so you can start at once.

In your context it would mean: First translate, then refactor. But this means 2x work.

Or, first, the legacy code needs to be analyzed and understood properly. Then "the refactoring" takes place as a "rewrite" - having the legacy codes structures by side for look ups of disered return values or similar...

But, that's the problem of the lead to recognize that. It's a problem of the whole team, so everyone knows what parts are when and how rewritten and what classes/objects/functions are to be expected from the fellow coworkers...

That's how I would do that haha but I'm completely unexperienced in working in teams :(

So, dunno if this could help you and dunno whether it's completely bullshiat - what this probably can show you, is:

every brain is unique and you have to find your own way to handle that. There are no quick solutions or advices for this kind of problem-solving...

One answer also could be: Train your programing skillz. While true, it's a no-brainer.

Peace.