We don’t use Sprints.
Sprints are difficult at the best of times for the Corporate Information Systems developer. First of all a fixed timeframe means that the deliverable is compromised. This is especially true of an end to end development – what we call a swim-lane – that includes the integration of data from Source to EDW to Star Schema to BI tool to Information Product.
Sprints work in AGILE OLTP systems because the deliverable is small and contained. Usually it is a set of data input and processing features built around capturing and processing a transaction in support of a particular business process.  So a small increment in functionality is not going to be particularly challenging.
In the CIS the deliverable is Data rather than Feature oriented.  That has a raft of implications. We, as developers, have to guarantee the semantic consistency of data from source through to the BI Information Product.
That influences our estimation of the Stories and the Tasks associated with their completion.
Our approach to this problem is to use variable length Iterations, each of which is determined by the team’s estimate of the time to deliver the increment of working software to satisfy a business need.  We don’t constrain the team to a fixed two week sprint because they could not possibly meet the deadline in a steady and controlled manner.
So our Iterations typically range from 2 to 6 weeks. The initial iteration tends to be short because we want rapid feedback from the Product Owner. Usually it is measured in days.  Once we get feedback we find the middle iterations require 4 to 6 weeks as the end to end integration issues bite. Once the end user is happy the latter iterations, UAT and Pre Production take one or two weeks. Typically that means we can build and deploy and end to end new requirement in as little as four and a maximum of ten weeks.
For us working software is the driver rather than fixed time boxing.