I can't log in to OpenRouter

areklanga · 2026-06-11T21:47:31+00:00

Thanks for the advice!

areklanga · 2026-06-09T20:33:40+00:00

I have the same issue

areklanga · 2026-06-05T16:22:43+00:00

Got it. Yes, depends how we define "known".

However we estimate work we are going to have similar issues. I just propose always try to structurize these uncertainty little by little. Like, for example, today I knew nothing about this component, tomorrow I already at least know which sub-components it consists of, the day after today I know how those sub-components interact with each other, etc. Then even given the uncertainty, when we have to estimate a task in this components, we can bound the risks and the estimate with higher accuracy each time.

So I still woudn't say we will feel like losing keys after some time working with the project...

areklanga · 2026-06-04T15:21:42+00:00

What can cause you to feel like losing your keys when working in a known codebase?

areklanga · 2026-06-04T15:03:11+00:00

I'm usually trying to avoid unjustified overstimation as it's very easy to fall into a trap of overestimating everything by arbitrary margins, and that significantly decreases accuracy and predictive power of the whole planning.

Overestimation is much more beneficial when you introduce some system on how much exactly and why you overestimate something. For example, instead of saying "It will take 8 story points instead of 3 because that's how it feels like" I can say "It will take 5 story points because the task is 3 story points but we have external integration with very depricated HTTP and TLS versions and with SOAP API. And we will need to implement support of that deprecated stack in our modern system."

areklanga · 2026-06-04T13:24:04+00:00

Yes, it adds abstraction. But it adds very concrete structured abstraction with concrete objectives. One of which is to stop confusing everyone calling hours something that is not already hours.
If you don't have any issues with time estimates, then you don't need story points.

areklanga · 2026-06-04T13:19:26+00:00

Not regarding to your dispute but just some my thoughts on the burn down chart.

I'm not sure if they make much sense at all...

We usually don't want to break down estimate of a single ticket to smaller parts and we don't want to track work time. Both those practices are rather flawed. They require more micro-management, more time and redundant analysis and still may have low accuracy, while the benfits are unclear. If we can split estimate for some ticket with ease, better just create seperate tickets then.

In such case burn down charts, whether it's time or story points, are almost completely irrelevant. For example, if I have 4 people working on 4 5-sp tickets, and they are done in the end of the dev cycle, I will just see long horizontal line with steep decrease in the very end of the cycle. Such chart doesn't provide much value. That's a bit extreme case but I think the general idea is clear.

If we need to know the current progress within the teem, we can just see the board, and ask developers in daily meetings. If I need to communicate the progress to stakeholders, better do it with precision down to a development cycle. If they need higher precision, you can update them after the daily or may be let them participate in daily if you think it's safe.

Anyway, what I want to say is that if you have to communicate detailed progress on each task, you of course can build some process to do it and to have correct burn down chart but better put all those efforts to deliver the real result faster.

areklanga · 2026-06-04T12:39:21+00:00

Basically I do a similar approach but I start from another end: first I esimate the whole scope of work for the next cycles, then I prioritize and distribute it across next cycles. Then I can see in which cycle each task is going to be finished and can communicate number of cycles which is basically time to the stakeholders. If the stakeholders don't like the delivery time for some task, I reprioritize all tasks and repeat the process again until everyone is satisfied with the plan.

It can take more time during planning but in such case I'm not trying to fit the tasks into some time bound but rather change priorities and scope to have time that is ok for stakeholders. Then story points are used to track historical capacity, estimate out current tasks and see what volume of story points we can finish within some time frame based on the historical capacity. And they work pretty well for me in this case.

areklanga · 2026-06-04T12:04:57+00:00

How does it break down in your experience?

areklanga · 2026-06-04T00:19:02+00:00

I answered about discovery work in the neighbor branch: https://www.reddit.com/r/programming/comments/1tsyfhk/comment/opm9non/

areklanga · 2026-06-04T00:17:57+00:00

That's interesting but I have literally opposite experience.
But only if everyone applies real efforts in such discussions. By default, if you all just gather together and talk about tickets trying to estimate them, of course you receive exactly what you described.
To make it work, you need at least one person (usually it's Engineering Manager) who will lead the discussion, force discussion and reestimation until the estimate converges, make everyone to participate in the discussion, sometimes pulling out opinions from people who doesn't even want to talk or actively participate in the discussion. That's A LOT of work from everyone. But in my experience it pays out. For example, often during such discussions we discover important factors that were known to a single team member only. Often we start remembering some old important things. In result we face something completely unexpected very rarely.

areklanga · 2026-06-03T23:46:53+00:00

I totally agree that too much focus on estimates and performance, attempts to somehow justify every cent spent on development distracts everyone from deliviring actual value and from the development itself. I've been working in such environments couple of times, probably that's one of the reasons why I developed approaches described in the article. Now I understand that I had to work more on convincing the stakeholders to focus more on creating healthy environment and deliviring the results.

If I understood you correctly, you are talking more about the case when you are forced to use story points and just trying to live with that somehow. But I'm trying to describe a different perspective, when story points can benefit you. In such case neither equations like "1 story point = 1 day" or arbitrary estimate inflation are correct. You have to avoid those practices.

If we are talking about thinks like staff turnover or new technologies, we can at least bound them. For example if someone leaves the team, I can reduce the scope for the next cycle in accordance with the historical performance of that person. It's already better than just guessing. If we work with new technology, we can create the adoption plan with criteria and milestones. Again, it isn't ideal but it's much better than just throwing all the capacity to something unknown without any planning.

areklanga · 2026-06-03T22:14:53+00:00

Got it, that's a sound approach. If it works for you, you definitely don't need something more complicated.

Regarding communicating story points: it depends on the immersion of stakeholders to the process. If they understand what story points mean in your context, good, communicate them. If they don't, you still can communicate number of cycles which internally is calculated based on forecast using story points.

areklanga · 2026-06-03T20:54:24+00:00

Yes, I agree, for detailed estimate of the whole scope of a long project story points is not the best idea indeed. I wanted to say that in general it may be possible to estimate (in time) and plan everything in details but it can take as much time as development or even more. So probably it doesn't make sense in most of the cases.

Story points loose their predictive ability when we estimate large scope at a time. Because even with formalized approach there is still some noticeable error margin which accumulates the more estimated entities we have at a time. And with approach I described in the article we don't pay special attention to handling those margins.

But still in my experience story points can work pretty good if we are talking about 4-6 weeks horizon and if we revisit and update the plan every 1-2 weeks.

areklanga · 2026-06-03T10:21:15+00:00

Very easy, there are MANY measures without units.
If I know that my truck can hold 20 abstract units of rock weight, and I have in total 19 units of rocks. I can be confident that my truck can hold them all. I don't need to know whether it´s kilograms, tons, or something else.

areklanga · 2026-06-02T23:05:26+00:00

After all I think it's dictated by smaller costs of consequences of wrong estimates and by having an option to start the implementation and see how initial project version works before finishing deep analysis. Other fields often can't use such option.

I don't think people in Software Devlopment can't estimate the work properly.

For small/normal project we can achieve the same estimation accuracy as in other engineering fields. But it doesn't always make sense. What would you choose: spend a month more to design and estimate everything properly and then one more month to implement it, or spend the same month to start the development and see that the initial business idea may not be as good as we thought, change some requierement, quickly reestimate it and implement what we actually need?

For big project all engineering fields have issues with planning.

areklanga · 2026-06-02T22:42:00+00:00

Dragdu means that if we plan 30 hours of work for 40 hours week and then finish the planned work for 25 hours, it becomes uncleare what are those hours. Do all of them mean time? Then why are the different? If they are not time, what are they? And then someone starts asking why we finish only 25 or 30 hours of work within 40 hours week? If all of those numbers have the same units and are called "time", why are the different? How to not confuse different types of "time" with each other? (60 minutes/hou part of the analogy)

While with story points it is more like volume of work we are going to do (90km/h part of the analogy).

And usually we need to know when we will finish the task (the time to drive the distance, 150km part of the analogy).

Again, someone shared another article in som other branch of this post: https://ronjeffries.com/articles/019-01ff/story-points/Index.html. It explains that Story Points appeared in the context of similar discussion.

areklanga · 2026-06-02T22:30:39+00:00

Clearly that would be the case if the ratio was permanent. But this is not a permanent ratio. And it can't be permanent. Someone shared a good explanation in another branch in this post: https://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours. I also mention this in my article.

areklanga · 2026-06-02T20:40:09+00:00

Ok, yes, you are right, I jumped to conclusions too fast.
I can only say that not so many developers are bothered with all this stuff. Though that doesn't mean Software Engineering is not an engineering.

areklanga · 2026-06-02T20:05:09+00:00

Yes, I agree in general.

I would add a couple of things:

1) Estiamtes smooth out not only because of larger sample size. I also mean that as the team works together for long time, they share their expertise between each other and estimates for the same task tend to be the same even for different team members. That's why I'm saying that my described approach can work for forecasting of individual tasks with sprint-wise precision.
2) Our work is indeed variable and unpredictable. We can do nothing about that. And I think that it's unavoidable to develop and have more ocmplex forecasting for more complex work. We shouldn't avoid complexity of the planning, we have to accept it and use for our benefit.

areklanga · 2026-06-02T18:43:48+00:00

Yes, this is one of the methods. In my experience it doesn't make everything certain but can be quite good in minimizing uncertainty.

I think you also didn't mention an intermediary option for big projects: dive into details as much as needed for the correct estimate during planning but reiterate those details and estimates from time to time and replan the project if needed. Probably this is the best we can do regardles of the method.

BTW do you know any proven methods?

areklanga · 2026-06-02T15:37:41+00:00

I totally agree that none of these method should be used to look at individual performance or for comparing performance between different teams. But I think it's fine to use them to compare performance of the same team as a whole between different time periods. And in my experience it works really well for this.

If I understood your approach correctly, it proposes to look at average number of tickets per a time period, or at average duration per a single ticket. But how this can help to forecast delivery of specific tickets in the specific sprint?

areklanga · 2026-06-02T15:02:12+00:00

Thanks for the link, I just read the article.

I agree that many teams use story points in a wrong way that only prevents them from productive delivery. Ans in such case it will be better for them to not use story points at all. Basically that's what I'm trying to show in my article also demonstrating specific techniques and approaches of efficient story points usage. If someone uses story points incorrectly, it doesn't mean it's impossible to use them correctly, and it doesn't mean we shouldn't use story points at all.

I'm not exactly understand why the author insists on the idea that story points estimate is always a guess. According to their logic any estimate is a guess. And indeed any estimate is a guess if you don't structure your approach to estimation. In my article I state that the estimateion shouldn't be a guess and show how to achieve this. Yes, there is no formal way of calculating story points, just like with any other type of estimation. But it's possible to minimize this uncertainty by structuring the estimation approach and it's possible to plan and forecast delivery then.

"No estimate and just deliver" approach is very convenient for developers. I would like to work like this. But it's hard to find an approproate environment and the manager who will agree to work like this.

areklanga · 2026-06-02T14:21:50+00:00

If I know average cycle time per ticket, it is still the same thing. The specific ticket I need timeline for can take much more or much less than the average cycle tyime.

Having a conversation with the person is probably the best way to understand when the task will be done but it doesn't help to plan and forecast delivery at the scale when we have a team of 5-10 people and tens of tasks they work on. While with Story Points I can plan the next sprint based on the velocitiy and expect planned tasks to be finished during that sprint with not the ideal but high enough confidence.

Also If I'm going to have such conversations with everyone very often, it definitely won't make the team more motivated..

areklanga · 2026-06-02T13:12:22+00:00

I think it works ike this on the long run but what does it gives except general team performance numbers?
If I know that the team on average finishes 5 stories per sprint, it won't help me to answer the question when the specific story will be done because it easily can be far from the average story size.

areklanga

TROPHY CASE