As far as I understand we don't estimate or plan a whole project in Scrum. More over the requirements are allowed to change freely. So does this mean that there can be no schedule for a Scrum project?
In particular, we can never give an estimate of when we complete a Scrum project?
Yes we can, planning in Scrum is done at three different levels: daily planning, iteration planning; release planning.
From team's point of view, the release planning gives us the direction, the iteration planning gives the structure and the daily planning gives the context for the next days.
All the planning allows risks to be identified early and so we're indeed free to revisit and update the release plan as we see fit (at least once per iteration is the ideal).
It's important a good communication so that expectations and requirements are clear so that you keep things on track.
I wrote about this recently elsewhere, and I'll revise and extend my remarks for this answer.
First, let's define project-based software: It is software that is meant to be defined, planned, developed, and delivered, and then the project is considered 'done'. A common metaphor used is relating it to building a building.
Scrum is an agile methodology, and if you read the agile manifesto, one of the values that jumps out is responding to change over following a plan, that is, if the organization practicing Scrum responds to change but they ditch the plan in the process, that's OK -- in fact, that's celebrated as being agile to change.
There are (at least) three parties involved in project-based software:
Scrum as a methodology is centered around ensuring the people who use the software and the people who build the software work as close together as possible, and in some way the only role that is both the 'customer' and the 'business' is the product owner role.
Already we can see that Scrum is perhaps not the best methodology for project based work. It does not align well with the roles 'needed' for project-based work (Asking a product owner to choose between the two masters of the customer and the people approving the budget and the customer will lose 9 times out of 10).
If you're deadline driven -- that is, if following that project schedule is the most important artifact to your business and culture (and that's OK if it is!), then you will inevitably feel like scrum is 'getting in your way'.
To determine whether Scrum is an acceptable methodology to your business for project-based work, culturally you need to understand the business' appetite for change. Are they OK if the team does not make commitments outside of two-weeks/four-weeks in advance ? (whatever the sprint length is)? If the team says, "We don't know when this will be done, but we have a relative degree of certainty what we can get done this sprint?"
I am even hesitant to write the above because in the 2011 iteration of the Scrum Guide they changed commitment to forecast, underscoring the idea that the Development team isn't really able to commit to work, they can however make a forecast, with about the same accuracy as a weather forecast two weeks in advance.
Does this unsettle you or your business? If it does, scrum may not be for you, as its process is not tuned to the schedule being the most important thing.
When there is a deadline and a scope, one must always choose one or the other when they are not aligned. Scrum chooses to cut down the question to What can we do next? instead of what will we get in the end? Scrum can't answer what the 'end' will look like, but Scrum can help you iteratively get to wherever/whenever that end is.
Estimates for completing a Scrum backlog or some portion of a backlog are certainly possible and are often done by measuring velocity and deriving a burn chart.
However, the first principle of the Agile Manifesto is "early and continuous delivery". If you achieve that then project "completion" arguably matters very little. If a team is regularly delivering new and valuable work then the most important question is not when do we stop delivering?, but rather: what should we work on next?
Scrum and agile development are a response to the problem of software projects being extremely difficult to schedule, and most project schedules being little more than a collection of guesses. Switching from waterfall to scrum isn't losing your schedule, it's admitting that you never really had one in the first place.
Software isn't like construction, where you know how long it takes a mason to place one brick, and can multiply it by the number of bricks in the project. It's more like the architect drawing up the plans; the size of a wall doesn't matter, only its interactions with other things.
