Wednesday, April 1, 2015

Sprint Duration

Some colleagues and I have been thinking a bit about the duration of a Sprint or Iteration and have decided that having a fixed duration is a bit of nonsense.


First of all it forces us to plan our cycles in an awkward way by putting filler into an iteration. This causes a few problems since it pits focused effort in more than one context. Instead of discussing, planning and developing the login feature we end up doing those for login and search, for example.


Secondly, it requires that we break work up that takes over the arbitrarily chosen timeframe. This is generally a good thing, but can lead to awkward breaks in the work and improper elaboration and planning. Say for example that the team decides to do one part in Sprint 1 then the rest in Sprint 7 because other things were more important. Now months have passed and of course now there will be rework because the elaboration of the final piece took place while Sprint 6 was under way.


Our take on it is to scrap this whole idea of arbitrarily time-boxed sprint cycles and base the cycle off when some feature/story/chunk of work is ready to go. Perhaps some minimum time would be appropriate. We are a small shop and we aren't set up to branch by feature. If we could, then features could be pulled rather than pushed. As it is, we can push per feature.


There is another reason for the push per feature method. When code sits too long, it grows fuzz. That's the only way I can describe the phenomenon. Somehow when we revisit the code we wrote months ago it grows little fuzzy edges of mystery that were once perfectly clear in our minds at the time. Ah well I guess that smell means we better clean it up again and introduce more risk, right??? I guess this could happen if your feature B in Sprint 7 has a shared dependency or please don't say it, shared code with feature A from Sprint 2. Now what you do! Retest Sprint 2!? Ha!!

No comments:

Post a Comment