= 27d567bc2d48d9f40e9ccc20ea370b15)
sixes_and_sevens comments on [Link] How to see into the future (Financial Times) - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (13)
My inside perspective is that story points aren't an estimate of how much time a developer expects to spend on a story (we have separate time estimates), but an effort to quantify the composite difficulty of the story into some sort of "size" for non-developers (or devs not familiar with the project). As such it's more of an exercise in expectation management than forecasting.
This is something i have tried explaining multiple times, but I cant really say that i understand the point. It's harder, so it takes longer, right? My response is that it is a combination of time to complete and probability that the estimate is wrong and it takes a lot longer. But it seems to me that it would be better to decompose those aspects. The benefit of putting it in one number is that it is easier ti use to manage expectations. It's like giving an estimate that is higher than your true estimate based on risk. Frequently, you should end up with spare time that you use to offset the reputational impact of totally missing sometimes. From a manager's perspective, it looks a bit like padding the estimates systematically, to offset all the biases in the system towards only hearing the earliest time possible.
Max L