Idealistic vs. realistic sprint planning:

Idealistic:
p1: "Can you tell us why you think this user story deserves 9 workdays?"
p2: "Of course. We are using framework xyz for part ABC of component y, so if we were to adopt changes in this, we would need to do new test planning and adjust accordingly. The complexity is of linear time and so -"
p1: "Interesting. I had not thought about that. Let us discuss more"

Realistic:
p1: "Ok so, how long?"
p2: "um, 9 days"
p1: "k"
p2: "k"
p1: "and you?"
p2: "yeah 4 for this 2 for this 1 for this, rest is ok"
p1: "aight, meeting concluded gg"

The idealistic one can happen if there's team trust, but usually there's team dysfunction which causes for team silence and brewing of product issues later on. If only reality weren't this sad.

More realistic:

p1: I need to you roll a dice for me.

p2: OK, give me the dice.

p1: No, first you have to tell me what the score's going to be.

p2: I haven't even seen the dice yet, it could be anything.

p1: You can at least give me an idea, I need it for this spreadsheet.

p2: Alright, I'll be surprised if it's less than 1 or more than 6.

p1: Come on, everyone else is taking this seriously, why can't you?

p2: Ffs. Ok, it's going to be a 4.

p1: Thank you, that wasn't so hard now was it? Here's the dice.

p2: Wait, this is one of those joke dice with sex positions on it.

@donkulator LOL

Isn't the second one about trust? They give you estimates - you take them without doubts. The first one is micromanagement/scepticism and not trust, and frankly annoying unless there's actually something to discuss and not just "justify to me the time, because i don't believe you"

@iiii It's part of the industry-standard Testing Framework called Planning Poker, one of the ways to do agile test planning. If you don't specify and discuss in detail, problems surface later on. I know this from experience as well. The agile testing framework also specifies that things should be discussed continuously and openly.

@CaptainRant frankly, planning poker is borderline useless: either all more or less agree, because all know what the task is, or the estimate will be false and off by a lot, because no one knows clearly what the task is. Discussions are good and should be held if they are meaningful, but most tasks, from my experience, don't require them.

@iiii Interesting. It depends on the task complexity and category. Trillion-dollar industries often require thorough specification across the whole pipeline because of accountability and audits, so it's not strange to see user stories specified in detail with pre-req, input, output, acceptance criteria, verification criteria, validation criteria and attachments and comments of the story owners and reviewers explaining the business case etc.

why are they cutting you off and then telling you to discuss more, gosh, such hypocrites. every time!

simplicity is best otherwise you get distracted playing poker

I'd agree that just use hours or something. why are you introducing random complexity that's not relevant to your goals?

planning poker iirc was invented to throw off micromanagers, but of course it doesn't work once micromanagers "learn" the artificial complexity. the guy who invented it thought management's brain would be too small to gamify the system, and didn't realize just how tirelessly motivated micromanagers are

if someone has a bad spirit there is no magic tricks you can do. all the tricks do is outrun the problem, if you're more clever and putting in more effort than the other guy. but the root problem is you just have a person on your team that has the wrong spirit for the team to be functional. their intentions are not aligned with everybody else's. and that's going to trip everyone up, if not now and if you can setup a pole vault wall in front of them, then definitely later when people think it's "fixed"

@jestdotty Rofl. 'cause they want to feel powerful. They do that with everyone that's not their favorite.

@jestdotty I get irritated when a software product doesn't have a full and complete specification. I despise unclear requirements that then drag onto tons of meetings trying to get out of the confusion mess.

Micromanagers are annoying. Having to track every day wtf you did and how many hours you did it. Sigh. If the bad spirit is the Scrum Master then you're fucked.