Over a million developers have joined DZone.
Platinum Partner

Agile Decompiled: Sprints

· Agile Zone

The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.

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.

The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Learn more about driving business innovation by leveraging Agile quality lifecycle strategies.


Published at DZone with permission of Chris Odell , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}