<story><title>I don’t believe in sprints</title><url>https://www.robinrendle.com/notes/i-don’t-believe-in-sprints/</url></story><parent_chain><item><author>rob74</author><text>And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the &amp;quot;big picture&amp;quot; of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what you wanted to have.&lt;p&gt;To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...</text></item><item><author>hurril</author><text>This is nothing but a bad strawman from start to finish.&lt;p&gt;Sprints are not made to help organize things, they&amp;#x27;re a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability.&lt;p&gt;This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place.&lt;p&gt;Nobody has to like it, this is probably not the best method and maybe it&amp;#x27;s not even good. But the author misses the point completely.</text></item></parent_chain><comment><author>the_af</author><text>What would be the alternative without sprints?&lt;p&gt;What specifically about not using sprints would help the team if they lack good planners and people capable of seeing the big picture?&lt;p&gt;Isn&amp;#x27;t such a team screwed regardless of how they allot work?</text></comment>
<story><title>I don’t believe in sprints</title><url>https://www.robinrendle.com/notes/i-don’t-believe-in-sprints/</url></story><parent_chain><item><author>rob74</author><text>And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the &amp;quot;big picture&amp;quot; of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what you wanted to have.&lt;p&gt;To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...</text></item><item><author>hurril</author><text>This is nothing but a bad strawman from start to finish.&lt;p&gt;Sprints are not made to help organize things, they&amp;#x27;re a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability.&lt;p&gt;This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place.&lt;p&gt;Nobody has to like it, this is probably not the best method and maybe it&amp;#x27;s not even good. But the author misses the point completely.</text></item></parent_chain><comment><author>specialp</author><text>Well yes it does require some dedicated PMs, owners and leads. If you are a smaller operation that does not have this, sprints might not be as beneficial. But if you are working for anything at scale as a developer, sprints aren&amp;#x27;t necessarily to track every hour of your day, it is to give you a structured path of things to do without having to know every detail about the bigger picture&amp;#x2F;compromises with product&amp;#x2F;prioritization. Also as a developer it gives you leverage because you were given certain tasks for the week so when someone comes along and tries to inject &amp;quot;high&amp;quot; priority item X, something else has to give.&lt;p&gt;I found before I was on the planning&amp;#x2F;lead side, it was hard when you did not have this structure. People would still shove in &amp;quot;small&amp;quot; tasks without a sprint structure and then months later it is hard to explain why a big project did not ship on time. So if done right and not abusively by oversubscribing devs, it is a great too for both sides.</text></comment>