Scrum and Agile Manifesto 

Some people start using Scrum although they know almost nothing about the Scrum. It makes me really sad when I meet people with the following mindset "Scrum == Sprint". Yes, all they know about Scrum is that you have to work in some iterations called "Sprint". And at the end of the project they are so disappointed because the project was not as successful as they expected. That is because the Scrum is dramatically different from traditional sequential development.
Every Scrum team member must be familiar with the basic values of Scrum. That's why I decided to wrote 12 posts about the foundation of all agile methodologies including Scrum: Agile Manifesto Principles. In every post I try to will explain one principle in a very simple way.
Here is the first principle:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
At the start of the new project you have to answer one really big question, what exactly are we building? The short answer is, that you must build the software that is going to be of value to the customer and will satisfy their needs. But in the reality it is not so simple to achieve that.
In the sequential development project you would first start with a lengthy up-front requirement-gathering phase. The result of this phase would be hundreds of pages of detailed requirements documentation where all features are equal important. Let's face it, the customer don't care about documents and UML diagrams and it is hard to get the right information from the customer and put it on the paper. They just want to get the software that maximizes the added value to their business and they don't know exactly what that value is on the first day of the project. There is a big chance that there will be some disappointment on the customer side when the software will be presented for the first time at the end of the project, although the software works as at it is described it the documentation.
There is a total different story with Scrum teams which adapt early and continuous delivery of valuable software because the client is involved throughout the lifetime of the project. That is how you can get early customer feedback and valuable emergent requirements. Scrum team documents all the features in a product backlog, which is a master list of all desired functionality not yet in the product. Product backlog is also known as prioritized feature list and priority is assigned based on the items of most value to the business or that offer the earliest ROI and value. Product owner has to groom the product backlog continuously because items are added, removed and reprioritized each sprint as more is learned about the product being developed. The result is that the most important and highest-priority items are implemented first because they are found at the top of the product backlog.
Agile Changing Requirements
This is the second post in the series of 12 posts about Agile Manifesto Principles. They are the foundation of all agile methodologies and every Scrum team member should be familiar with them.
Here is the second principle, that talks about change:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
In software development we all strive for a projects where customer would never change their minds. And we all know that will never happen because changes are inevitable in real world. Customers usually do not see a problem of changing requirements as a serious one.
Traditional development process prefers sticking to their well-thought-out plans that are the result of the requirement-gathering phase. Introducing change late in the development process is costly because you need to repeat the whole waterfall process (analyse, design,...) for each change.
Agile methods take a different approach and treat change as an expected and welcome part of every project. After all, it is all about satisfying the customer because it is necessary to preserve customer's competitive advantage.
During the project the customer can continue to make changes, as long as they prioritize these changes in the appropriate iteration. Product owner is responsible for understanding of the customer needs and grooming the product backlog (prioritizing work based on business value) even near the end of the project. It is even better to make decisions later in the process when we have a better understanding of the product that we are building. Because a product backlog is a living thing that evolve constantly it can respond to the actions of customer's competitors. Agility is all about flexibility and being open to change is a big advantage.
You need to remember the following two words about this principle: welcome (changing requirements) and harness (change)!