3 ms·

> intended to encourage incremental development of complete software systems I've always seen that mainly accomplished by breaking large stories into smaller o

• vannevar 4y ago
  Breaking a story down into smaller stories is not the same as incrementally developing a complete system. This is the difference between reductionism (breaking a large pre-defined project into smaller pieces for execution) and holism (always delivering a complete system, but incrementally extending the functionality as the team learns more). Sprints provide the time increment for the latter. Note that a sprint increment may differ from project to project. But most teams find 2-3 weeks to be a good increment. Even in a reductionist approach, though, sprints provide a regular opportunity to review the appropriateness of the breakdown or the validity of the parent story.
  • jrib 4y ago
    You make a really good point on the importance of having a complete iteration at the end of the sprint. In my experience, the fixed time increments have always felt too constraining. I think a team can accomplish a similar goal of having regular incremental progress in the form of complete systems by relaxing the fixed-length sprints requirement. The alternative that I favor is Kanban with defined releases. A release, as a collection of features, is a complete system, but it doesn't necessarily have to be finished in the same time that the previous release was. A larger release may take six weeks instead of the smaller previous release that only took one. You make a lot of good points, thank you for sharing your thoughts.