1

Let me share my sprint with you.

So, we lost a developer this at the start of the sprint because the organisation we work for is total cancer.

Project manager frequently says to us that it's better to under commit than over commit.

Come sprint planning, we commit to exactly what we know we can achieve.

Of course, the PM whinges and says we need to put more in the sprint. So, we say sure, but we can't guarantee we will deliver everything on time.

Fast forward 2 weeks, we complete 90% of what we committed to.

PM is whinging at stand ups, asking us why some user stories are still in 'ready for test'.

We try to explain to the PM that 2 weeks ago we made ourselves very clear that this point 2 weeks later would most likely happen.

PM stops whining.

Tester starts whinging about only having a couple of days to test. Blames developers for not adhering to acceptance criteria.

>User stories aren't actually user stories, they're user essays.

How do you deal with this?

Comments
  • 1
    That's the normal state for scrum. Just one reason it perpetually sucks. To fix the suckiness, don't do scrum. Preemptive strike on comments about "devs swarming to help QA, and bs about succeeding or failing as a team": that's called mismanagement and inefficient use of your resources (and another reason why scrum sucks)
  • 0
    What you are doing isn't a fully implemented scrum. The user Stories shouldn't be longer than a one day task. Otherwise they need to be split into multiple stories before sprint planning. Additionally there should be a priority list for the stories to do. You work according to that list and PM can only put the leftover tasks into the next sprint again. They should not have been started in the first place.
    And PM is not a regular participant in daily meetings, only if asked for by the team.
  • 0
    @Shiggy "Shouldn't be longer than one day tasks" I've never heard this before. And it's nonsense. Another reason scrum sucks: after complaining that all estimations are flawed and that we should use points or t-shirt sizes, scrum proponents hypocritically assume that tasks estimated using such unicorn fart units are magically accurate and scrum masters become irrationally upset when they are not. News flash, many tasks take longer than a day. Coping them up into smaller bits is just inefficient dogmatism. Plus, doing so leads to piece meal crap software ( pretty much most commercial software these days)
Add Comment