The sprint. The timeline of an agile team. The sprint is the “timebox” that you use to get your stuff done. It’s an iteration as you want to keep having sprints over and over.
You might have many sprints make up a release, you might have one sprint make up a release.
Your sprint could be a number of different timeframes.
I suggest 2 weeks.
Why 2 weeks? Well, it is enough time to get things done, but not have too much to worry about, it also ensures that things you want to get done are done in a small enough time frame so that the people that needs to see your outputs don’t have to wait longer than 2 weeks. 2 weeks also fits nice as 4 weeks could almost be considered 1 month.
Other alternatives? 3 weeks – might be the only other time frame I would suggest using, but then remember, if you have something get requested before a sprint, and you can’t get it into the current sprint, you won’t see that story completed for 6 weeks!
1 week is too short, you are just constantly churning. 4 weeks is another one that some teams use, but again, it could be 8 weeks before seeing something. The world just moves to fast for that kind of timeline.
Other options are doing staggered sprints. 2 2 3 2 2, or 2 3 2 3 2, etc. It can get confusing, but doable, I haven’t seen a reason to do it yet, so I have kept to the 2 week timebox.
I also recommend starting on a Tuesday, Wednesday, or Thursday. If you run your sprints say, from Tuesday, 2 weeks, you end up ending on a Tuesday afternoon. Same with Wed/Thurs. And you can do your Sprint Planning on that Tuesday/Wednesday/Thursday. When you use Friday and Monday, things just get tough to plan around. You probably never want to release on a Friday, people like to take vacations and days off on Fridays, tec.
Another tip, don’t treat a sprint like a mini-waterfall project. You will end up in trouble. Try to test/validate completed stories as they get completed by the do’ers. Waiting until the end of a sprint will lead to pile up of things to do.
Throughout the sprint, the product owners and requester of features should be in the loop (for one, with the Daily standup) but also they should be seeing the fruits of your do’ers labor, they should be seeing the output and features as they are completed.
Releasing at the end of the sprint is key. If you can’t, then you should at least have things in a “potentially shippable” state so you can demo and test it for the people that have requested it.
Other things you can do with your sprints. I like to separate out things into their own “mini sprint” when needed. An example might be, Upgrading your infrastructure to SQL Server 2008. You can’t really work on things on your servers when they are being upgraded, so at the end of a sprint, say “the next week is a mini sprint for the upgrade” and then pick up your regular sprint schedule after that. Same thing with holidays. Over the Christmas and New Year holiday you may have a 2 week holiday sprint. Just let your do’ers do research or something fun they have wanted to do. Most people will be out of vacation anyways.
Treat your sprint though like you would treat your daily standup. You don’t (you really can’t – or it screws up things) want to keep adjusting your days and length very often. The more you adjust the more it confuses people and the harder it is to try to get your actual velocity.
Pick a date to start, pick a timeframe, and stick with it. Try to stick with it for a year, at least 6 months before totally changing things up. Discipline, just like the daily 15 minute standups. Keeping things standardized and set helps your team and others know the schedule and keep things on track.
Steve Novoselac's Blog 