what is max sprint in agile

A Sprint is always 30 days or less. As soon as a Sprint ends, a new one closes. Check out https://www.scrumguides.org/ for the official Scrum Guide.

Hope this helps.

Agile doesn't have Sprints. Scrum has Sprints, and (as Chris said), the maximum duration for a Sprint is 30 days.

Jira is not necessarily an Agile or Scrum tool. It has the ability to support Agile practices, which includes Scrum, but it also allows for other approaches. For example, consider if you wanted to use Jira to support an organization that was doing something similar to Basecamp's Shape Up - you would need an iteration length of up to 6 weeks.

Actually it is NOT 30 days or less folks. 

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.  -Scrum Guide

It is a calendar month or less, therefore it can be up to 31 days, 30 days, or 28 days for certain months and then when good ole Leap Year comes around it could be 29 days. On that same note, you can actually have sprints less than 1 week (exasperated gasp while thinking "WHAAAAAT???"). That's right folks, there is not a single thing that says you have to have sprint lengths determined by the week. 

Curtis, it depends on which definition of "month" you use. Merriam-Webster defines a month as "approximately 4 weeks or 30 days". Leixco by Oxford says "a period of 28 days or 4 weeks".

Using a calendar month harms empiricism if you have Sprints that are sometimes 28 days, sometimes 30 days, sometimes 31 days, and rarely 29 days. If you are adding and removing calendar days (and therefore likely working days), it becomes infinitely harder to measure accomplishments per timebox. Having an extra day or two can be a big difference in the amount of work that can be done. Also consider that "Sprints have consistent durations throughout a development effort." Since months have varying lengths, using a calendar month would not give you a consistent duration throughout a development effort that lasted more than 2 or 3 months.

You cut that definition short, from that link it states:

1: a measure of time corresponding nearly to the period of the moon's revolution and amounting to approximately 4 weeks or 30 days or ¹/₁₂ of a year

The 1/12th of a year is important since we have 12 months in a year. 

Using a calendar month harms empiricism if you have Sprints that are sometimes 28 days, sometimes 30 days, sometimes 31 days, and rarely 29 days. Also consider that "Sprints have consistent durations throughout a development effort." Since months have varying lengths, using a calendar month would not give you a consistent duration throughout a development effort that lasted more than 2 or 3 months.

The issue here is that you are comparing a fixed measurement against a varying measurement and attempting to use them the exact same way. Scrum is a framework with limited rules, "one month or less" allows more freedom than "4 weeks or 30 days".

I'm going to disagree that using calendar month harms empiricism. Why would Jeff S and Ken S intentionally put something in the scrum guide that would hinder the very foundation of the Framework they created? Personally, I think that having the scrum guide use "one month or less" opens up for more empiricism as it allows teams more freedom for experimentation. This allows for teams that need to follow a calendar month schedule to still utilize scrum. If the sprint time box were a strict 4 weeks or 30 days, that actually hinders the ability for teams to grow and utilize the most appropriate sprint length for their product and company while staying in the time box limit. Again, days and weeks are fixed lengths; a day is always 24 hours and a week is always 7 days. A month, however, does not contain a fixed number of days or weeks, it is a varying unit of measurement. If you make sprints a max of 30 days, that really can muck up the sequence throughout the year, you'd end up with a sprint starting in the middle of a month after a while which would cause even more confusion than it is worth. Most teams set their sprint length by week, 1,2,3, or 4 week sprints. That works for them and that's great, but for the teams where that doesn't work, they have another option by utilizing a "one month or less" sprint length. 

I stand corrected, it is one calendar month. Some good discussion! We also have a book authored by  Ken and Jeff wrote a book called "Software in 30 Days".  ; )

I doubt there are many contexts where a calendar month would be preferable to four weeks, because most organizations and their staff operate heavily around weekly cycles, breaks at the weekends, meetings on certain days, and so on.

But if an organization does have a strong monthly cadence, or if a market is set up in such a way that there would be an important Inspect & Adapt moment at the same time each month, this sprint length might be useful.

It's a maximum. It's not necessarily the best option.

Time-boxing helps, along with other benefits, by reducing overhead and complexity. As stated in the Scrum Guide,

»Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.«

Isn‘t it much easier to remember planning is always on a, say Tuesday, than looking up the day taking into account the length of the current month, or count up »30« days?

In the mentioned book, »Software in 30 days,« the authors seem to view 30 days as 4 four weeks. For instance, then they discuss sprint lengths, they halve or double meeting times when they compare »30 days« to »2 weeks«. See figure 6.6.

To me, I‘ve never even thought about 30-day-sprints or calendar month-long sprints.

Exactly Simon! I think was evidence of wisdom by Ken and Jeff by having the max set as “one month or less”. Is it the best or even normal? No but it allows for more freedom and for those fringe teams that would run it by a calendar month, they don’t have to change their cadence.