5

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.

Comments
  • 6
    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.
  • 2
  • 4
    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"
  • 0
    @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.
  • 3
    @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.
  • 0
    @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.
  • 0
    @jestdotty Rofl. 'cause they want to feel powerful. They do that with everyone that's not their favorite.
  • 1
    @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.
Add Comment