Yeah, it's a trivial difference. If people are digging in that hard, that conversation seems like a good proxy for other problems with the team. I've had vote

Yeah, it's a trivial difference. If people are digging in that hard, that conversation seems like a good proxy for other problems with the team. I've had votes split between 1 and 2 a number of times. That's a 2. (My planning poker algorithm is: 1. Vote without discussion. 2. If the votes all agree, that's the number of story points. If the votes are within 1 of each other (1, 1, 2; 2, 3, 3; 8, 8, 13) then it's the highest (2, 3, 13). 3. If there isn't that much consensus, then someone with the lowest vote and highest vote complete the sentence "To do this task..." 4. GOTO 1) This is unbounded, of course, and sometimes no consensus can be reached. That usually means more definition is needed, and you can take on a task to do that definition for the next planning meeting. When there is disagreement, it isn't always bad. Sometimes an old hat will say something is a 1, and the new person that just joined the team will say that it's a 13, and the senior person will say "To do this task, edit foo.yaml and commit it." and the junior person will say "To do this task, I need to set up my workstation, then build a test environment, then read all those getting started instructions, then get access to production, ..." and you'll realize "Oh shit we never had the setup onboarding meeting" and you can just do that. Whereas if you just said it was a 13 and assigned it to the junior engineer, they still wouldn't be onboarded after struggling through all of that on their own. I don't want to sound like an agile advocate or anything, in fact I'm pretty disillusioned by agile, but I've used this before and don't have a big problem with it. Looking at story points over a period of time is good for taking on the right amount of work in any given cycle; if someone says "we need to launch this next week" and your team does 15 story points of work per week, and the project is 1000 story points, then you know that that can't happen. Numbers to prove it! Someone can work on reducing the scope in the meantime. I think people try to get way too much out of agile, like on day 1 setting launch dates for features a year out, and that will never happen. That is why people are disillusioned, "I set up a 6 hour sprint planning meeting and bought a JIRA license, and we still aren't launching 3 new features a month!" Yeah, the actual work is still time-consuming; moreso on a larger team with changing opinions and changing markets. So it goes!