IT Scene and Changing Trends from an Indian Perspective

Udayan Banerjee

Subscribe to Udayan Banerjee: eMailAlertsEmail Alerts
Get Udayan Banerjee: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Virtualization Magazine, SOA & WOA Magazine, Java Developer Magazine, Microsoft Developer, CIO/CTO Update

CIO/CTO Update: Blog Feed Post

Four Prerequisites for Reducing Sprint Duration

Factors influencing sprint duration

Agile manifesto has explicit stated preference for shorted sprints. Shorter sprints can ensure that:

  • “Parkinson’s Law” does not set in, that is work does not expand to fill the available time
  • “Understanding gap” between users and developers gets ironed out quickly
  • “Quick response to change” becomes possible

However, there are other factors which may make too short a sprint cycle counter productive.

Factors influencing sprint duration
There is a certain amount of overhead associated with each sprint. Every sprint requires some initial planning time plus validation, regression testing and integration time and effort at the end. This overhead is proportional to the total size of the software and the level of automation in place and does not depend on the number of stories delivered during the sprint. In short…

Do not attempt short sprint cycle without a mature engineering practice.

Otherwise, it would lead the team to burn midnight oil and lead to frustration.

If the product owner is always available for the team…

If all the stories are clearly spelled out…

If there is no confusion or disagreement on how the user stories are to be implemented…

…then short sprints are fine. Otherwise, stories cannot be delivered in a short sprint.

Do not attempt short sprint cycle without clear user stories.

But longer sprint may not be a solution because it will only introduce slack and waiting time. So, better idea would be to create a buffer of clearly defined user stories. Applying Kanban principles may help.

Third key point in deciding the sprint duration is the amount of time and effort required to implement a story. Several factors may influence that:

  • Architectural complexity
  • Existing technical debt
  • Skill level of the team

So …

Do not attempt short sprint cycle if, for whatever reason, the team cannot implement stories fast enough.

In short

If you need to have short sprint cycles, do the following:

  1. Improve your engineering practice to bring down the sprint overhead
  2. Ensure availability of clearly defined user stories
  3. Simplify your architecture and reduce technical debt
  4. Improve the skill level of the team

Related Articles

Read the original blog entry...

More Stories By Udayan Banerjee

Udayan Banerjee is CTO at NIIT Technologies Ltd, an IT industry veteran with more than 30 years' experience. He blogs at http://setandbma.wordpress.com.
The blog focuses on emerging technologies like cloud computing, mobile computing, social media aka web 2.0 etc. It also contains stuff about agile methodology and trends in architecture. It is a world view seen through the lens of a software service provider based out of Bangalore and serving clients across the world. The focus is mostly on...

  • Keep the hype out and project a realistic picture
  • Uncover trends not very apparent
  • Draw conclusion from real life experience
  • Point out fallacy & discrepancy when I see them
  • Talk about trends which I find interesting
Google