4 ms·

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to mee

by termau 8y ago

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself

monksy 8y ago
That or having to estimate work based on your sprint. This is a 130 pointed task? Oh we only go up to 8.
srtjstjsj 8y ago
Are you saying you have projects that show 0 progress of any kind after 1 month, but still succeed later? What is happening in that first month?
- lordnacho 8y ago
  Laying the foundations. Doesn't look like a house even after you've done it.
  - AnimalMuppet 8y ago
    Exactly. You need the end-to-end backbone working so that you can start adding end-to-end user-visible behaviors on it, a few at a time.
- s73v3r_ 8y ago
  Research? Experimentation? Foundations?
  - Melchizedek 8y ago
    Pffft. We're talking crud apps here. Has any innovative software ever been developed in "sprints" using "user stories" and "story points" with a "product owner" and a "scrum master"? I doubt it.
    - AnimalMuppet 8y ago
      Yeah, I've been on a couple of those. It was XP, technically, not scrum, but we did sprints and user stories and story points, and we had a product owner, and we had a guy who was de facto the keeper of the methodology. It worked really well, too. And no, it wasn't just crud apps. It was a distributed security auditing tool. Yes, it had a database component, but it was much more than that.
nradov 8y ago
It's best to break up user stories into small vertical slices and implement them within a single sprint so that you can get early feedback from the customer. That's a great way to uncover misunderstandings about requirements, even though it might seem less efficient. Optimize for rapid value delivery; a little wasted time is acceptable.

4 ms·

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to mee

by termau 8y ago

monksy 8y ago
That or having to estimate work based on your sprint. This is a 130 pointed task? Oh we only go up to 8.
srtjstjsj 8y ago
Are you saying you have projects that show 0 progress of any kind after 1 month, but still succeed later? What is happening in that first month?
- lordnacho 8y ago
  Laying the foundations. Doesn't look like a house even after you've done it.
  - AnimalMuppet 8y ago
    Exactly. You need the end-to-end backbone working so that you can start adding end-to-end user-visible behaviors on it, a few at a time.
- s73v3r_ 8y ago
  Research? Experimentation? Foundations?
  - Melchizedek 8y ago
    Pffft. We're talking crud apps here. Has any innovative software ever been developed in "sprints" using "user stories" and "story points" with a "product owner" and a "scrum master"? I doubt it.
    - AnimalMuppet 8y ago
      Yeah, I've been on a couple of those. It was XP, technically, not scrum, but we did sprints and user stories and story points, and we had a product owner, and we had a guy who was de facto the keeper of the methodology. It worked really well, too. And no, it wasn't just crud apps. It was a distributed security auditing tool. Yes, it had a database component, but it was much more than that.
nradov 8y ago
It's best to break up user stories into small vertical slices and implement them within a single sprint so that you can get early feedback from the customer. That's a great way to uncover misunderstandings about requirements, even though it might seem less efficient. Optimize for rapid value delivery; a little wasted time is acceptable.