The Scrum Guide has this to say about the roles:
The Product Owner
The Product Owner is responsible for maximising the value of the product and the work of the Development Team. How this is done may vary widely across organisations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog.
The Scrum Master
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Business Analyst
Not actually mentioned…
The Business Analyst role is one that seems very common (and potentially very useful) addition to the team within Scrum. Their key role to facilitate understanding between the Product Owner/Business and the Development Team.
The Business Analyst should have the whole system view to reflect the single story view the developer/tester would have and so can answer the queries and fill in the details for the developer/tester.
We heard about a team where they were actively working to embed the BAs within the Scrum Team. As part of this journey the BAs were demoing stories at the Sprint Review!
In some instances the BA can proxy for the Product Owner, for example representing the PO in the Scrum ceremonies.
This does really depend on a significant level of trust from the Product Owner and it was not expected that the BA would sign anything off. Sign off of stories being the sole responsibility of the Product Owner as the single wringable neck.
We could also say that in effect the business analyst can be the person responsible for the mechanics – logging of stories, ensuring they are sprint ready etc – of the backlog while the product owner is responsible for the underlying content and priorities.
One common concern/problem is where the Product Owner and/or Business Analyst and/or Stakeholders are not fully engaged with the Scrum team. They tend to have a day job or are looking to the next project. In order for the Agile process to work we need someone who is empowered to make a decision – for example if a feature is Done, and we need some representative of the Business to at the very least engage with the ceremonies in Scrum in order that problems and progress can be be communicated in a timely fashion.
This lack of engagement can lead to delays in the delivery of the product – if a story isn’t signed off we would have to bring it forward into the next Sprint – this impacts average velocity and has further implications on any planning and delivery estimates. All to often this issue is never factored into why a project is apparently behind schedule and it’s the Scrum Team who are blamed.
Do we let the the project fail where we don’t have this engagement?
No Gods No Masters
One interesting case was of a team who had “lost” their Product Owner. This begged the question how did they determine what to work on?
The team received requests from the business and had an overarching road map of what projects were needed and there was a simple request of just do it. The team then determined the stories, the priority and when they expected to deliver. The Scrum Master controlled the Backlog adding the stories and tracking the work. Products were being delivered and the Team seemed happy with working this way.
The team had absorbed the Product Owner role and had enough subject matter knowledge to create viable stories.
Crazy? Well if it works…