> 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.
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.
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.
If you told someone on Monday that a ticket takes two days they’ll ask you on Thursday why it’s not done.
Instead story points combined with team velocity give your team a sense of how much work you can commit to.
Of course we all have in our mind that a 5 point story takes a like 3 days.
If some director or product leader comes in and looks at these tickets the won’t see any time estimates on them and thus can’t hold you accountable to them. Sue they can look at your team velocity. But that’s generally a higher level moving average of several sprints.
Of course this is all imprecise and often isn’t implemented well. I’ve seen it work very well for some teams, where it gave us a good sense of our accomplishments and led to more ownership. It often doesn’t work and just adds overhead.
I’ve ditched it for my current team.
In any case, I was talking about the many devs who insist it's not time even though it is. Having it be a sort of abstracted or obfuscated time increment is fine imo.
Story points are simply a way to say "I think that looks roughly like twice the work of that one we estimated before".
Usefulness depends on specific environment and who and for what interprets the output (usually, at some organization level, there's excel/Gantt, that will convert them into an exact date. That will fail spectacularly in 99% of the cases).
Well, who's planning to do it?
In mine - not so much. Two dev team? Sure, you probably know. 6 dev team? Not so much. Estimation, then back to customer to decide if they'll eat the cost and decision 2 weeks later? Good luck knowing what will happen then.
Point is answering question "does it fit into the sprint", knowing that usually you can fit 3 big tasks and 3-5 small. Then real time estimate is end of sprint.
And by "twice the work" they mean takes twice as long. It's still time.
Anyway you could just say "2 days of work" with the understanding that duh, a senior can do it quicker than a junior. It's just an estimate anyway.
It's weird how people whose half of work is coming up with clever abstractions, have so much problem with that one.
Maybe estimation is complex thing and therefore team needs to align opinions before doing it?
That's why points aren't really necessary. Using days is still an estimate.
That said, I don't really object to points, I object to the idea that they don't represent time, when they obviously do.
Who is doing the work? The senior? One day. The junior? Three days. The estimate should always be done by the person doing the work. This also forces people to have skin in the game when making estimates. When you have a full team coming up with points, then no one has any consequences for being wrong. But if you say one day, then you have some incentive to think things through. You want to live up to your commitment. Of course, this assumes that there are some consequences for being wrong, which usually isn't the case. I think this is where many people go wrong with time estimates. If you're repeatedly wrong, that's not because time estimates don't work. That's because you're bad at them. And like most skills, if you do them repeatedly and try to learn from the cases where you failed, you'll get better at it.
The engineering manager should know the product area and code well enough to gauge the LOE for tasks and plan, without the unnecessary step of estimation meetings (which likely aren’t going to produce accurate numbers anyway).
Could also be a tech lead that does this, but prefer that they’re one in the same.
Of course there are many aspects of “pure scrum” I don’t agree with, such as a single sprint goal shared among the team
Use story points. Succeed with story points. But don’t try to convince yourself (or me) they aren’t just an analogue for time.