I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on.
I think you are right that much of that is driven by managers looking for metrics, but unless they understand what the metrics mean it is pointless.
I think there's value in that debate (within reason) even as a developer. If Alice thinks a task is worth 5, and Bob thinks it's worth 8, then there's a good chance one of them knows something the other does not. Is Bob aware of some hidden complexity that bumps it up 3 points? Or is Alice familiar with a convenient library that solves exactly that complexity? Planning poker is a convenient time to get that knowledge out into the open.
Again, this is all within reason, and if it takes 15 minutes on every ticket, the team should probably work on their communication skills.
Everyone is correct in this thread. The stimulation of discussion is useful, and numbers are arbitrary.
Instead of worrying about 5 vs 8 though, the team should be discussing relative difficulty: is story B easier/more difficult/complex than story A? And then ranking stories based on the relative difficulty of each other.
Story points can then be derived based on that ranking, if the team chooses. They're useful for being applied to velocity calculation, and also helpful when picking up a story to work on (maybe a bad idea to start an 8 pointer on a Friday).
(I have a SM cert, working as a TPM. I applying Agile principles to teams, but modified to how they want to work and be most effective. No militant Scrum here.)
That for sure seems useful. "Hey Sally, you think B is harder than A. Why do you think it's hard?" "Hey Bob, you disagreed with Sally and think B is easier, why is that?"...is very likely to lead to a useful conversation in terms of everyone getting in sync and may well lead to hidden information being brought out into the open, which is a good thing. In general I think relative value/preference type conversations tend to reveal a lot.
Attention! Discussing story points is no longer allowed during planning. After voting, teams are to discuss relative story points, swapping points between each two story. This is expected to increase efficiency and coherence. Rule enforcement commencing beginning of next month after the first weekend.
My experience is that in well-running teams, devs are usually pretty aligned what these numbers mean. A difference in proposed points for some task does then usually mean there's a discrepancy in knowledge about it.
As for its usefulness: You of course don't have to necessarily poker to get these discrepancies, but it's a pretty effective way of going about it, I'd say.
Exactly this. It's probably not an accident that one of those numbers is half of 10 (and the number of fingers on one hand) – a common made-up number for everybody – and the other is 2^3 – a common made-up number for programmers.
I've always done planning poker with the Fibonacci sequence - 1, 2, 3, 5, 8. The idea being that the more complicated the task, the harder it is to estimate accurately.
Why is story point estimation tied to fibonacci sequence? Two generations of managers at my previous employment thought this way. It just seems so arbitrary to me.
First, the more difficult a task is, the more inherent difficulty there will be in "accurately" estimating the difficulty of the task. Fibonacci is used to represent the inherent lack of accuracy in more difficult tasks, since the numbers get _very_ far from each other as they go up the scale.
Second, the numbers _are_ arbitrary. Completely, 100% arbitrary. It's a _relative_ difficulty scale. Say you've got 3 tasks - A, B, and C. A and B are approximately as hard as each other, they're 1 story point. C is more difficult than either one - it gets 2 points. That's it. Story points are not, and should not be used as, a unit of measurement. The biggest utility is to identify big, scary tasks with lots of unknown factors.
The fact that they are _numbers_ is what tricks so many teams/PMs/management/etc into thinking that story points are more meaningful than they were ever supposed to be. Incidentally, this is also why some planning poker teams use t-shirt sizing (S,M,L,XL,XXL, etc). No numbers means people are less tempted to punch them into a spreadsheet while deluding themselves into believing that showing numbers going down is the same thing as "showing progress".
The closer the numbers are together the more time is wasted trying to be exact about them. Fib helps reduce the amount of back and forth. If you need to guess how much something weighs and your options are 1,2,3,4,5,6,7,8,9,10,11,12,13,14.....100, you are going to have a lot harder time achieving consensus than if you asks "Is it heavier or lighter than a breadbox?"
My team doesn't really argue about points next to each other (on the Fibonacci scale) anymore, we just pick by majority and move on.
The conversation is meaningful when it's about 3 vs 8 because exactly as you say, there probably is some hidden complexity not everyone knows about, or sometimes some work has already been done or there's a framework feature that makes it easier than it seems.
But 2 vs 3 or 5 vs 8... this is explicitly designed to be an imprecise number, so let's not waste our time debating which one to choose.
My team has a rule that if your Fibonacci point estimates are within one of a given unit, you just accept that estimate with no discussion - so if I think a story is a 3, and others think 5 and 8, we’ll take the 5 and move on. I think it gives a good balance of discouraging hair splitting and surfacing cases where having more discussion is actually valuable.
If you will do something different with a 5 than with an 8 then yes. If not, then the ambiguities you describe will be worked out when you do the work. It is just a vanity metrics if the results doesn't change what you work on next. It seems important but it has no actual bearing on the teams sequencing of the work.
If Bob had a plan for doing the work that didn't involve Alice's library, there's a good chance he would have just jumped straight in to implementation without talking to anyone, and maybe the library wouldn't have come up until code review (if at all). By identifying the complexity mismatch ahead of time, they saved 3 points worth of effort. This doesn't affect sequencing at all, but still seems valuable to me.
Or Alice is more familiar with that section of the code and would move more quickly in there and Bob would be doing more learning along the way.
Quick discussion of the differences is useful, but 15 minutes is ridiculous. Just take the higher value and move on. Eventually you’ll baseline at slightly more points per sprint on average, but they are imaginary numbers anyway and not really comparable across teams.
My last job, we each had a minimum required individual velocity in our weekly sprints. That velocity score was the same if you were a junior or a senior. So in that case convincing the team it was an 8 could mean the difference between keeping your job or not. It was the most soul destroying, stressful job I have ever had. The worst was the Rockstar programmers not seeming to grasp that by reducing the points total on a hard ticket they were dooming their teammates. It lead to everything you can imagine, tickets implemented as fast as possible so they met the letter of the ticket but crashed on anything not defined as the team raced to meet their velocity. Massive unpaid overtime and burnout. Constant crashes in production. Races to claim the 'easy' tickets, and sandbagging. Eventually culminating in 8 of 12 devs quitting in an 8 month window including all seniors. My new job is so much better.
Sometimes importance is related to size. Points are arbitrary, but lets assume that on average a developer will work the entire sprint on an 8 point task. The PM might decide that feature is not worth the time investment in that sprint, if they could instead get 2 smaller features out the door, or some bug fixed - they might prefer to deliver that to stakeholders.
That's why there's even a velocity expressed in points, like the tasks - it's the PM's budget to work with. So 5 points or 8 doesn't change the work you have to do as an engineer, but it changes the number of things a PM will put on the team's plate in the next sprint, and the points force them to make trade-offs, otherwise they'll insist that the bug, the small feature and the large feature are all high priority and have to be delivered in the next sprint.
I'm not justifying the 15 minute time investment for sizing, that is clearly way too much time, I'm only highlighting that in scrum, as an engineer, you don't necessarily know or decide what the next most important thing to work on is. That's the PM's job.
Bugs get resolved desk-side five minutes after being reported and pushed through on PRs that have 89% test coverage (still green!). Developer is a cowboy hero! The good thing is: you always get more bugs like this so everyone gets a chance to be a hero.
My last "team" was constantly paralyzed by this. The scrum master would go around and everyone had to vote on the number of points they thought a story was, which then led to extended debate. Of course, it can always be worse...near the end, they tried some idiotic thing called "planning poker".
1. Sometimes your team needs to give an estimate of when it will deliver a feature. The idea of pointing in Scrum is that you establish a velocity, which lets you get a feel for how long it's going to take to deliver a given piece of work.
2. Sometimes your team needs to make trade-offs, and often the right lens here is ROI. You can't estimate ROI if you don't estimate the I. (Although I believe agile tends to somewhat overrate the usefulness of the ROI lens.)
3. In the absence of 1 or 2, the act of pointing can help to catch the case where you miss a piece of complexity; if someone thinks it's 8 and everyone else is a 5, then maybe they are aware of some gnarly code that everyone else has forgotten?
I'm not arguing in favor of discussing each story to death, just making a more general justification for the practice. If you never need to do 1 or 2, then maybe pointing isn't going to be useful for your team at this time -- and that's OK too.
I'm sure in some cases this is just driven by managers needing metrics to measure their teams by, but the above is an attempt to suggest some reasons that the teams themselves might find the practice useful.
Metrics are not bad. Story points and velocity are usually bad metrics though.
It's not a coincidence the consultancy sector uses scrum. They get paid for their output, usually by the hour, and scrum measures output.
If a consultant implements a load of useless features that make a product worse, but do so very quickly, then that's a great success for them. It's not fundamentally different from rewarding developers for the number of lines of code they write.
I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on.
I think you are right that much of that is driven by managers looking for metrics, but unless they understand what the metrics mean it is pointless.