4 ms·

In my experience, every scrum project I have been on became an exercise in satisfying the requirements of scrum, versus the requirements of the project. I actu

by ejb999 3y ago

In my experience, every scrum project I have been on became an exercise in satisfying the requirements of scrum, versus the requirements of the project. I actually had multiple scrum masters tell the developers that if they finished their assigned stories early, and there was still time left in the sprint - don't start any new stories, wait until they next sprint officially started, because it made the reporting better to upper management. People like that need to be fired.

rgblambda 3y ago
>don't start any new stories, wait until they next sprint officially started I think there's room for this kind of thinking, if the end of sprint is tied to a release, and spare capacity gets redirected to helping complete existing stories (both those things need to be true). I've never been in a team that did that though so I don't know how well that would work in practice.
- philomath_mn 3y ago
  You can start on new work even if it doesn't get merged that sprint. Especially thorny tickets where 90% of the work happens before any code is written. But I agree with your point about assisting others on existing stories (if help can be given).
sgarland 3y ago
My experience in writing (or performing) user stories for scrum was also annoying. Was someone else’s story too vague, but you know what actually needs to happen? Too bad, kick it back and make them write down what you already know. Did you write the story with such explicit requirements that there is essentially only one way to accomplish it? Don’t do that, because <reasons>. I hate scrum. I’ve found that poorly-done Kanban is also a nightmare, unfortunately. I’ve yet to find a happy medium.
adamredwoods 3y ago
They do need to be fired because they don't understand scrum. What you get done, was above the line. Any extra stories one completes, is below the line, which means it does not count towards the sprint goals.

by ejb999 3y ago

rgblambda 3y ago

>don't start any new stories, wait until they next sprint officially started I think there's room for this kind of thinking, if the end of sprint is tied to a release, and spare capacity gets redirected to helping complete existing stories (both those things need to be true). I've never been in a team that did that though so I don't know how well that would work in practice.

philomath_mn 3y ago
You can start on new work even if it doesn't get merged that sprint. Especially thorny tickets where 90% of the work happens before any code is written. But I agree with your point about assisting others on existing stories (if help can be given).

sgarland 3y ago

My experience in writing (or performing) user stories for scrum was also annoying. Was someone else’s story too vague, but you know what actually needs to happen? Too bad, kick it back and make them write down what you already know. Did you write the story with such explicit requirements that there is essentially only one way to accomplish it? Don’t do that, because <reasons>. I hate scrum. I’ve found that poorly-done Kanban is also a nightmare, unfortunately. I’ve yet to find a happy medium.

adamredwoods 3y ago

They do need to be fired because they don't understand scrum. What you get done, was above the line. Any extra stories one completes, is below the line, which means it does not count towards the sprint goals.