Recent searches
Search options
There are a lot of agile software practices that make a lot of sense, but I'm not a fan of the idea of a two-week "sprint".
I end up having a dozen features half-done, because each had to be ready by the end of the "sprint". I'd much rather spend three weeks each on eight of them, and have the other four dropped entirely (or handed over to someone else).
This isn't just a quality vs. quantity trade-off, because a well-done feature saves time spent on future related features.
@jzillw If one is doing SCRUM "right" (not an easy thing) then this shouldn't be the thing
You either increase the sprint time if the tasks REALLY take that long OR if things are half done, they haven't been sized correctly during planning
Management tends to treat this as having something to hold against the team every two weeks but the idea is (supposedly) that the reason for the sprint is "protection against clients clienting"
Because every sprint turn is an opportunity to pivot [+1]
@jzillw The team commits to a certain set of "stories" which are all individual bits of functionality that CAN be implemented within the sprint (however long that is)
And then if suddenly you need to do something entirely different that doesn't come into like "okay, so client wants this tomorrow, lol". The idea is these things get filtered through the whole process and become stories for the next sprints....
So yeah, it's a thing with a specific purpose, for solo projects, it makes less sense