Category Archives: Sprint

Sprint announced it will expand its open location platform by adding TechnoCom Corporation to its open service enabler program, promising developers more avenues to create location-based solutions optimized for Sprint devices. TechnoCom is a location-based aggregator that provides customization and integration support services enabling call centers to offer location-enhanced services to customers and handle calls more efficiently. According to Sprint, applications could include solutions identifying a company’s nearby stores or office locations and location-based routing to the most appropriate call center or agent.

Sprint launched the open service enabler program in late 2008 with Veriplace and WHERE–last summer, the operator added Alcatel-Lucent, Loc-Aid and Useful Networks. The open service platforms guard the privacy and security of Sprint subscribers while offering third-party mobile, web, WAP, SMS and widget developers a more consistent method to build applications that incorporate customers’ location information to deliver customized information and services.

In related Sprint news, the carrier said its Developer Sandbox program now includes both iDEN and CDMA capabilities, meaning programmers can now create and test applications for the Nextel and Boost Mobile brands. Sprint Developer Sandbox, launched in mid-2009, features tools to enable more efficient creation of location-based services, messaging apps and related solutions–the initiative is open to all Sprint registered developers, and provides access to network, handset and product capabilities.

For more on Sprint’s latest developer efforts:
– read this release

While Google’s updated Android 2.0 operating system officially reached the consumer market in early November in conjunction with Verizon Wireless’ commercial launch of the Motorola-produced Droid smartphone, Sprint announced the revamped OS will not expand to its Hero and Moment devices until as late as mid-2010. “Happy to announce Android 2.0 is coming to Sprint’s Hero & Moment,” reads a Dec. 11 post on the operator’s official Twitter feed. “Date TBD, but roughly 1H 2010.”

According to IDG News Service, the delay underscores the potential fragmentation challenges facing the open Android platform as it spreads across more operators and manufacturers. With various smartphones running Android 1.5, 1.6 and 2.0, there exists the possibility that not all Android applications will function properly across all addressable handsets, a situation that could discourage developers from creating software for the platform. “That type of confusion doesn’t give developers a warm and fuzzy feeling,” said Interpret analyst Michael Gartenberg.

For more on Sprint’s Android 2.0 holding pattern:
– read this IDG News Service article

Related articles:
Android 2.0 SDK touts messaging, browser enhancements
Android app project starts grow 94 percent in one month

Introduction

I may have blogged about this previously. I have written so many blogs, I can’t recall any more. However questions regarding Sprint length surface on the forums regularly.

As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context – this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.

The Context

A team of 5 members currently working with 10-day sprints. They haven’t managed in the previous 5 sprints to have 100% of the User Stories completed. It is typically around 60-70% completeness.

There is proposal to increase the sprint duration to 15 days “because doing review meetings and planning every 10 days is a lot of overhead” according to the team.

My thoughts

Let me start out by stating some facts …

The official Scrum sprint length is 30 days. However I don’t think (I don’t have facts to back me up on this but it’s the sense I get from all the communications on all the forums) there are many teams working to 30 days any more.

Much of the Agile community agrees that shorter Sprints are better. So 2 week Sprints and even 1 week Sprints are becoming more the norm.

Why are shorter Sprints better?

1. Well we have learned from the Lean folks that shorter Sprints means less work-in-progress which means shorter cycle times and overall less waste.

2. Additionally, shorter Sprints tends to stress your process, revealing any flaws. Like no automated build process, automated test harnesses our unit test frameworks. Fixing these flaws has a tendency to provide leaps in productivity gains for your organization.

So assuming you buy the argument that shorter Sprints are better. My initial quick answer to the question is don’t try to lengthen the Sprint. Rather try to figure out why you’re only hitting 60% – 70% of your originally committed goals.

By the way, 60% – 70% may not be that bad, after all you have a team that is currently demonstrating a consistent output Sprint after Sprint.

So that leads me to think that either the story point estimation is not consistent, or the team is just over-committing. So I would suggest that they do the following.

Try to really assess what is going on in the retrospective. Let team members speak freely about their thoughts on the matter.

I would definitely spend a little bit of time re-assessing the size of a few completed items i.e. if the story was 10 points originally, what would they estimate the size now, after the fact. Re-assessing the relative size may well fix the problem.

Some folks, most notably Ron Jefferies, would argue why do you need to get your estimation down pat. Well in my opinion for one, predictability goes a long way to help remove team stress. So its great for a team to say we can commit to say 100 points and deliver between 90 and 110 each Sprint. The business will love you for this.

Whats good about this problem in and of itself is that Scrum is doing what it’s supposed to do; surface issues for the team to resolve. And if the team feels that going to 15 day Sprints is the right thing to do, so be it – it might well be. But I would try to first figure out why 2 weeks is not cutting it. Many teams make it work so it should be doable.

Hope this helps if you’re in the same boat. If not at least if it provides food for thought!

Jack
agilebuddy