Agile Software Devlopment Methodology - The Sprint

I wanted to take the opportunity to talk about the benefit of sprints (or iterations) in the Agile Software Development Methodology...not from a developer perspective, but from a Product Management perspective. Our team sprints are 2 weeks. This means that we analyze the priority of features, estimate user stories based on their feature priority and task the team with two weeks worth of "work" to achieve a user experience by the end of the sprint.

The best feature that I like about sprint is the ability to "change gears" every two weeks! Any enterprise product needs the ability to support project work and meet high priority features for clients to "capture the sell". As the Product Manager, I'm the person with "boots on the ground". I get to talk directly with clients, sales teams and distributors to hear their requirements of the software. Although it's impossible to make every feature request a priority, it is within the methodology to change the priorities (every two weeks) to allow the software to demonstrate a feature that is a time critical request for a client.

There is a fine line that must be walked here...you don't want to impact the top priority features for a release, but there is plenty of room to achieve "quick wins" with existing large clients and prospective future clients.

The sprint allows me to reprioritize a "quick win" feature request to fit within the sprint and provide a thin line user experience to allow demonstration of the feature in 2 weeks.

Clients (and sales staff) really like to see their feature requests being demonstrated in two weeks! It demonstrates that we really develop the software for the client to meet their business needs and allows us to be "responsive" to cash flow potential. The interesting phenomena is that most of the time, the client is usually fine with the feature being "productized" and completed by the scheduled release date! By simply demonstrating that we are responsive to their needs shows a commitment to solving their business problems.

The sprint is also a great thermometer for measuring progress. At the end of every two weeks, I get to calculate the velocity of the team that accounts for the number of bugs resolved and the number of user stories estimated and completed in the sprint. It gives us a continuous monitor on our ability to estimate features, our ability to rapidly address bugs and the ability to complete user facing features. Analysis of velocity allows us to continuously evaluate the planned feature set for the release to effectively manage resources, money and time!