I know that the best sprint length will vary from situation/company to situation/company. That being said, has anybody had success using flexible sprint lengths? Also, I wondered if anyone has strong opinions about short (1 week) vs. longer sprints?
Background: We currently develop using 1 week sprints. Our product owners seem content with this; however, for the sake of flexibility, I have asked a couple of times to increase sprint length for certain projects. In all cases, we stick to the short sprint.
As usual: it depends.
I'm currently in an organisation where sprints vary between two to four weeks. I'm not keen on this personally as it becomes difficult to gauge velocity, and also tricky for the rest of the organisation to match their schedules with the development team.
On the other hand it does mean that very few stories are carried over to the next sprint, and we can more easily take account of absence, unexpected bugs, and suchlike -- which would normally lead to a sprint being cancelled outright.
I've been involved with teams that have tried the one-week sprint. In practice the amount of overhead associated with sprint planning, test plans, deployment and suchlike meant that we ended up with about two days of actual development time: it was hard to get large strategic work done as a result. I believe that team now work using Kanban and no fixed sprint duration at all, and are much happier as a result.