How does your team answer that question? If your team cannot credibly answer this question based on empirical data, you are missing a key element of iterative, incremental development.

One of the goals of iterative, incremental frameworks such as Scrum is to enable stakeholders to make informed business decisions based on the reality of the effort at hand. That does not come for free, or without wrapping our heads around some new thinking. "When will we ship?" If you want your team to answer "we will ship at the end of sprint X" with credibility, then a number of things have to be in place.

• First we need release goals expressed in business problems to solve, not fixed lists of features. This allows the team to validate that their solution is solving the problem, as well as negotiate the solution that is needed today versus the robustness that can be added later.
• Second we need a generally stable, regularly refined Release Backlog that is sized in relative terms such as story points. This gives us a target against which to measure progress.
• Third we need teams to routinely make and keep delivery commitments sprint by sprint. This give us a reality based measurement of progress ("Velocity") from which we can project a future path. If the team cannot build credibility toward achieving sprint goals, there is no reason to believe in any answer they might give with regard to shipping the release.
• Fourth, we need teams to work toward a consistent definition of "done" and to have the discipline to abide by it each and every sprint. "Done" defines what we mean by "shippable". However well intentioned, we cannot accept "done" statements like we are "done", except for the final UI; or we are "done" except for the documentation; or we are "done" except for these 3 defects. We need to know the true "done-ness" of our software, good, bad, or ugly. Otherwise any assessment of a progress toward a delivery date is meaningless.

With these things in place and working together, the decision to ship shifts away from being a technology decision and becomes a business decision. From the delivery team's point of view, we can ship at the end of any sprint if the business stakeholders believe sufficient business value has been generated to warrant the release. The business can now manage the Release Backlog to set the right expectations of what business value is desired for the release, and we can use the team's historic velocity to project when that work can be completed. That is the purpose of the Release Burnup such as the one below. "When will we ship?" "Based on the current size of the Release Backlog and the team's average Velocity we will ship Release Burnup Chartat the end of sprint 9." No guess work, no hedging, no wishful thinking. Empirical data tells us an answer based on the reality of the work already completed; and that answer is refined at the end of every sprint.

Because velocity varies from sprint to sprint, we may prefer to look at a range of dates to answer the question. In that case we can also state our best and worse case scenarios considering the highest and lowest velocity of the team's past sprints. Then our answer becomes "We will ship no earlier than sprint 8, no later than sprint 11, and most likely sprint 9". All based on realistic, empirical data about the current state of the effort.

Armed with this evidence the business can make informed, reality-based decisions on how to increase the value delivered in every sprint. The delivery team can pragmatically refine (smooth out the variance of) its velocity, and look for ways to work more effectively to potentially increase its velocity. Better yet, all of these things can be done early enough in the process to realize positive change in the overall effort. That's why we are doing Scrum in the first place.

When will you ship?