lawrence19 (u/lawrence19)

TulliusCicero · 3 years ago

But by "complexity" people pretty much always mean "how long it'll take", so it's still time. If something was complex in an abstract way but quick to implement, it would get a small number of story points, not a large number.

lawrence19 · 3 years ago

I don't disagree with you fundamentally, but maybe one way to reframe this is around the type of conversation we're looking to prompt when we point stories. The conversation you're describing (and to be fair that I mostly have experienced as well) is a one-way, "you owe us this, how long will it take?" conversation. The conversation I'm always hoping to have, and that I've seen happen before, is a bi-directional one in which tradeoffs are discussed, priorities are constantly shifting, thoughtful investments are planned, and engineering concerns are a first-class citizen. All of this can happen if you simply consider your estimates "time" as well, but I find that conceptualizing it as "engineering complexity" helps encourage an engineering mindset among the non-developers on a team.

TulliusCicero · 3 years ago

> story points (some vague relationship to days of work)

Watching people insist that story points are totally not representative of predicted time spent working on a thing is the funniest shit. The mental gymnastics are incredible.

lawrence19 · 3 years ago

Story points in my experience almost always devolve into time estimates, but I don't agree they have to be the same thing (which is how I interpret your use of "representative"). They are related variables in the same way that temperature and pressure are related, but that doesn't mean they are identical.

In a healthy environment, I think "story points" (horrendous name) should approximate "engineering complexity given the current state, skill set, and knowledge of the development team." Time estimates should then be derived from that number based on historical performance of the team in its current state (if you fuck with the team structure, all bets are off and historical data becomes less useful).

Ideally a team should use points to do thoughtful analysis of their backlog and think of ways to manipulate scope, invest in cleaning up technical debt, and learn new skills to cheapen the engineering complexity and in turn deliver faster. In practice, what you described is almost always what happens. Stakeholders keep pressing for time estimates, so shit just keeps getting added to the backlog and engineers estimate "how long?" because they are neither encouraged nor empowered to think of it any other way.