Scrum is an agile process framework for handling complex knowledge work, with an initial focus on software development, but it has been used in many fields and is slowly beginning to be explored for other complex works, science and advanced technologies.
The framework challenges assumptions of the conventional, linear approach to product development, and encourages teams to coordinate themselves by promoting physical co-location or close online collaboration between all team members, as well as regular face-to-face contact between all team members and disciplines involved.
It is structured for teams of ten or fewer members who split their work into targets that can be accomplished in timeboxed iterations, called sprints, no longer than one month and most usually two weeks, then track progress and re-planned in daily meetings called daily scrums in 15-minute time-boxed meetings.
A key principle of Scrum is the dual understanding that consumers will change their minds about what they want or need (often called uncertainty requirements) and those unexpected problems will arise — for which a systematic or scheduled solution is unsuitable.
To those responsible for the result, all work within the Scrum system should be visible: method, workflow, development, etc.. As such, Scrum adopts an empirical approach based on evidence – recognizing that the challenge can not be fully understood or identified upfront, and concentrating instead on how to optimize the capacity of the team to perform efficiently, respond to emerging demands and adapt to changing technology and shifts in market conditions.
Scrum is an empirical methodology guided by the feedback that, like all empirical process control, is underpinned by the three pillars of openness, review, and adaptation. To make these things noticeable, scrum teams need to evaluate the product being created often, and how well the team works. The team will spot with a regular review when their work deviates beyond acceptable limits and change their method or the product under production.
The owner of the product, representing the owners of the product and the customer's voice (or may represent a committee's wishes), is responsible for delivering good business results. The owner of the company is thus responsible for the inventory of the project and for optimizing the value that the team offers. The product owner describes the product in customer-centred terms (user stories typically), add it to the Company Inventory and prioritizes it based on value and dependence.
The Product Owner uses the analytical tools provided by Scrum to handle highly complex work while managing the risk and achieving value. A scrum team should have only one owner of the product (though the owner of the product may help more than one team). Not to mix this position with that of the scrum master.
The product owner will concentrate on the product development business side and spend most of their time liaising with stakeholders and the team. This position is critical and requires a deep understanding of both sides: the scrum team's business and engineers (developers).
As a result, a good product owner should be able to communicate what the business needs, ask why they need it (because there may be better ways to do that), and convey the message to all stakeholders, including the Development Team, using a technical language as needed.