Do scrum sprints have to be in weeks?

Granted Andrew, but why is say a 12 day sprint harder for the team to follow than a 2 week sprint?

Sante -

The specific duration of a sprint can be whatever makes the most sense for a team balancing the sense of urgency with a customer's appetite for value delivery. Week-based durations are convenient as the start and end days remain the same, but there's no harm with having a different duration so long as it remains fixed.

There is also the option to do away with sprints entirely and move to a continuous flow model - Modern Agile, Disciplined Agile and Scrumban all endorse that...

Kiron

To my knowledge Agile does not force you for weeks. What is advocates is ensure it is consistent over the sprints. It may be possible that your organization, development approach, environment may help you to execute 12 days sprint. If it is making performance to optimum, why not?

Just see if you can keep it below 30 days.

The sprint is the time-boxed container for Sprint Planning, Development Work, Sprint Review and Sprint Retro. The Scrum Team decides about the best-fitting Sprint length based on their experience, skills and what they can digest. So yes, if the team get to the conclusion is 12 days, they should go for it. Important is to keep this decision for some time. So, you do not change the sprint length after each retro. You only change after you experienced over a while of a couple of sprints a certain pattern, that gives the team good reasons to change the sprint lenght. According to Scrum Guide max. Sprint Timebox is 1 month as longer durations increase risk and possibly loosing focus.

A Sprint is time boxed, from one to four weeks, with a preference toward shorter intervals. Shorter interval is to help reveal problems/impediments faster. Sprint length can be chosen to any length depending on the complexity and size of user stories though I personally prefer two weeks sprints for most of my projects.
And yes a continuous flow model can also be adapted (I haven't worked with it yet)

Thanks Kiron, iteration length is interesting, so far I have never seen a sprint that isn't divisible by a week (other than a one month sprint), in other words I haven't seen one that is a certain number of days not divisible by a week, ie. 12 day sprints. The concept of "start and end days remain the same" should not matter in Agile, which is why I am examining this topic.

While 2-4 weeks is the common denominator if you read or work with the most recognized methods you will find there is not a general agreement. While it depends on the environment and context, here are some advice nysef and othersI contributed to create, while I do not agree with some of the points in the final result: http://www.agileadvice.com/2014/06/12/howt...-sprint-length/

Same reason for having the standup in the same place at the same time - allow the team to focus on the work. At least for me, it is easier to remember 2 weeks from start, then doing the math with an arbitrary number of days.

I understand the question is for the sake of discussion, however, the objective is simplicity. But, by all means, set the time-box at 12, 9, 4, 13 days. As long as it fulfills the need, and can remain consistent throughout.

I've worked with teams using a one day sprint length - of course, they don't do daily retrospectives and sprint planning merges with daily stand-ups, but break-fix teams often operate on a daily release model...

Kiron