Try and be more accurate about my estimated story points.

That will just come with experience and familiarity with the code

... and the eventual realization that story points are a time wasting crutch employed by companies that have no idea how to run engineering teams.

(:

@junon and story points are not so bad compared to time logging.

@PepeTheFrog Agreed, but they're both terrible.

@junon do you know what other companies use to track progress?

@-devpool- Tracking progress is an anti-pattern. There is no great way to "track progress", whatever that means. Knowing the state of a project means looking at the tickets and the roadmap and determining what is done and what isn't done. Once you start optimizing for a metric, that metric is no longer a metric (e.g. "tasks completed in a week").

You cannot streamline software development. This is a fallacy that very few managers seem to understand.

@junon that seems really insightful. And as an developer this looks like a really great way to measure to quality of a company in terms of work culture.

@PepeTheFrog story points are pretty meaningless with no strict definition.

@iiii you have to determine the definition and signification yourself without a doubt, which needs also to be understood by the team. Like you would define what log levels signify in a system.

It's a tool that is efficient for long term estimations when done right, but straight up trash when done poorly. I still haven't used anything better yet, but I am open to suggestion.

@junon but without tracking progress, how else do you determine how much man power you need to complete a set of projects or tasks for a milestone?

You need to provide estimates and heads up to customers at some point.

@PepeTheFrog You don't. You need to hire based on gaps in availability. You cannot throw bodies at a problem and expect it to move faster. That doesn't work in software - more bodies usually means slower release cycles because of the operational overhead needed to coordinate those bodies.

Further, your customers do not need specific dates. If they do, you're doing business strangely. Instead, if something is taking too long, have a meeting and discuss why that is. Discuss the things that are slowing development. Discuss possible improvements to efficiency given different resources the developers could utilize, potentially. Ask them what their time-sucks are (they will have a list, I'm sure).

Enable your developers to be efficient. Giving them deadlines and telling them "finish it by this date or else" is only making your calendar look nice and tidy. It doesn't actually solve the problem of efficiency.

Trying to find "estimates" is really just assigning deadlines. They don't help.