Software the Agile Way....

Scrum framework is deliberately light in defining this as there are many existing practices is requirement gathering that work well. Scrum does not want to impose any one style and allow the organisation to choose what is best for them.  Product Owner should  - Establish a vision for the project to constrain the scope  - Talk to his/her users and get high level business requirements.  - Order them so they give value to the organisation and meet the scope of the project (or change the scope if not originally correct)  - Work with the team to define what is a "Ready" requirement.  - With team refine them into functional requirements that can actually be built  - Constantly adapt as more knowledge is learnt or gained  This is a continual process

A project has a short lifespan, it has a start and and end. The product live is longer than a project.  A project may not necessarily deliver all Product Backlog Items, especially low value items. These may be postponed until a future date.  Defects and change requests happen post the project, these are added to the products backlog which can then be managed. A product backlog typically contains the following 3 types of stories  1. New features  2. Defects  3. Engineering - Stories for optimizing/refactor the current code, a effort undertaken to reduce the tech debt 

Neutral view points Inspection of Scrum implementation Coaching to improve Identify opportunities shield team from external disruptions remove blocks Facilitate communication Mediate conflict Incrementally help make changes to process Keep team focused