Sprints and longer term pieces of work

Consider decoupling the concept of a Sprint from a release. At the end of a Sprint, the Development Team produces an Increment that is Potentially Releasable. It may or may not actually be released at the end of the Sprint. The Product Owner may also choose to release some of the work while not releasing other work, even if the associated Product Backlog Items are Done.

Also, consider the size of Product Backlog Items. Even if the team will take many Sprints to complete a feature, I would still expect them to have something to inspect with stakeholders at the Sprint Review. Even if it's not going to be released to users, there should be the opportunity to obtain feedback to ensure that work is progressing in a useful direction.

Scrum is silent on how to manage work that spans multiple Sprints. It depends on the domain, the type of product, and the decisions made by the team. It's possible that the Done items may be releasable even through the full feature is not Done yet - the feature may be disabled or inaccessible in the released products. In other cases, the feature needs to be released as a whole.

I have a feature that will take 2 months to develop as it's quite major. How does this fit into the concept of sprints?

Waiting two months before seeing an outcome could be a substantial and expensive leap-of-faith. If increments of work are provided in short Sprints, might that provide an opportunity to validate critical assumptions behind the feature?

Any chance that we are talking about an epic here?

Epic (Jira terminology): Large body of work that can be broken down into a number of smaller stories that are usually delivered over a set of sprints.

I would take a deep look at this major feature and make sure whether it can be decomposed in smaller stories to fit in your 2-weeks sprints. Practically all PBIs can be subdivided further and 'groomed' by the scrum team so they cope well with their capacity and sprint length. The decission about when to release an increment  belongs to the PO so the 'releasability' of a feature might be taken into account or not, but it's not mandatory at the end of each sprint. As @Thomas said, also consider that the feedback you might get at the sprint review of the work done about this particular big feature may help to re-orient and detail the remaining work, even reject it (given the case) so no more time and resources are wasted.

Even though it may not be releaseble\testable as a standalone, the dev team will be able to break down the feature to a number of development tasks. Thes tasks can be added to PBI and can be treated as user stories.

A number of tasks from these can be taken up in a sprint and at the end of each sprint, these tasks can be evaluated.

--Anoop

Even though it may not be releaseble\testable as a standalone, the dev team will be able to break down the feature to a number of development tasks. Thes tasks can be added to PBI and can be treated as user stories.

If it's not testable, it's not a User Story, though.