Agile Zone is brought to you in partnership with:

I wrote my first program in Z80A when I was 14 on a ZX Spectrum and ever since I have been hooked. I love writing code of any flavour as well as being passionate about the coding process. I have worked professionally in the software industry for the last 15 years using Microsoft Technologies, and I code at night in PHP, HTML, Javascript and CSS. Chris is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Agile Decompiled: Sprints

06.25.2014
| 3618 views |
  • submit to reddit
One of the practices in the Scrum methodology is the sprint. A sprint is a short time frame in which to get the most functionality in a product within the time frame. The idea is that because there is such a short time frame the product owner is forced to focus on which features should go into the sprint, as well as helping the development team to focus on the work at hand and keep a tight control over product development.


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.

Published at DZone with permission of Chris Odell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)