Agile Decompiled: Sprints
However before sprints there was DSDM and timeboxing, which is very similar in concept and implementation. So even though Scrum sprints have been heard of by many agile teams, it is not a new idea.
The key aspect of any practice which makes the development team focus on what functionality to include/leave out, means that there is less likelihood of scope creep. If you have a defined time for delivering a piece of functionality it forces the team to sit down and make decisions about what needs to go into a product.
By keeping the time frame short the decision about what to put into the product during the time you have tends to be more cautious. At least in my experience. If targets are unknown or vague then it becomes very easy to underestimate the amount of work required to code a feature, and for the target to be missed.
I have also found that by delivering functionality regularly, users are kept happier, as they get functionality sooner, even if it is piecemeal. But another effect of delivering functionality quicker is that the development team stays more motivated.
I personally find that working on a large project for months and delivering a final version of the product can get de-motivating. At times you feel that you are getting nowhere and it can feel like you are walking through syrup. When I deliver features and functionality and see those features being used I feel like I am making progress, which motivates me a lot more to get the next features out.
So if you call your time frames sprints, timeboxing or something else. The benefits of this particular practice are clear, at least I think so.
Do you use timeboxing or sprints as part of your development process? If so I would love to hear what you do and how you do it.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)