5 ms·

I really don't understand the "sprints" approach to development - I've never worked on any project where it makes sense, either the things I've been working on

by olliej 4y ago

I really don't understand the "sprints" approach to development - I've never worked on any project where it makes sense, either the things I've been working on take less time than a "sprint" or they take longer, and that's for any sprint length you can produce. Real software requires some degree of planning, and sprints seem to be more an attempt to avoid that planning. I don't mean to the level of gantt chart hell (I've experienced that as well). Sprints, at least as they actually occur in the real world, seem to actively harm any large scale projects, and increase the overhead for long term projects if you can get them to fit.

pas 4y ago
there are different thoughs on this, but .. the team should not pick a task until it's clear what to do and until it's broken down into something that they think/agree can be delivered in one iteration. this is usually called refinement. (as the raw user requirements are transformed into a concrete design and then tasks) http://tryqa.com/wp-content/uploads/2014/12/scrum-methodology.gif http://tryqa.com/wp-content/uploads/2014/12/scrum-methodolog... if something is so unclear that the design/planning itself requires prototyping something, then that can be added as a task for the sprint. then when it's done, on the next refinement the team is in a better position to find a good design.