Product owner should know business analysis (Requirements gathering?) ??

However, what I read in couple of online articles is , "ideally" the product owner writes user stories.

Ideally, everyone on the Scrum Team should be writing Product Backlog Items as new requirements emerge.

Now, to write user stories he needs to  sit with stakeholders and elicit requirements. Ideally, as per the scrum guide this is not the role of product owner. Nowhere in scrum guide it's mentioned that product owner elicit requirements. Product owner is value maximizer. 

I think this is a misunderstanding. How will the PO maximize value if he doesn't know the needs of the stakeholders? 

1. It would be incorrect to state that product owner writes user stories (As mentioned in some of the online articles).

2. You can't avoid BA role in agile team. You have to have a Business Analyst in your agile team .

3. I want to ask you guys, in the agile project you work for so far, do all projects were having BA? If not, who used to write user stories?

1.) No, that would not be incorrect. The Product Owner should be writing User Stories. So should the rest of the Scrum Team

2.) If a Business Analyst can provide value to the development effort, then you should have a BA on your team. If they can't, you shouldn't.

3.) I've done both. Where no BA was present, the majority of PBIs was created by the PO.

Now, to write user stories he needs to  sit with stakeholders and elicit requirements. Ideally, as per the scrum guide this is not the role of product owner. 

Where in the scrum guide does it say that this isn't the product owner's role?  I will admit that the guide says the product owner (PO) can delegate the creation of the product backlog items (PBIs) to others but the "others" are intended to be part of the Scrum Team.  The PO is responsible for maximizing the value the team provides.  How better to do that than to be in sync with the stakeholders, market forces and company direction?

There is nothing the scrum guide that says a Business Analyst can not be part of the Development Team.  That team is a cross functional team of individuals that contains all of the skills necessary to accomplish the work to satisfy the PBIs. However in my experience, it is much more effective to have the PO talk to stakeholders and gather needs.  Then the Development Team and PO can discuss to refine the information into stories that can be executed upon.  By introducing a Business Analyst into the mix, it is much to easy to introduce bottlenecks or knowledge silos.  But as with everything I say, that is my opinion based on my experience.  Not all organizations are the same.  So if a Business Analyst is working for you and your Scrum Teams are delivering value to the stakeholders, then why change things. 

Scrum is a framework, not a descriptive process.  You define the process that works for your organization. 

Nowhere in scrum guide it's mentioned that product owner elicit requirements.

The Scrum Guide says:

Product Backlog management includes:

• Clearly expressing Product Backlog items

The Guide also says that the Product Owner may do this or have the Development Team do it, although the PO would remain accountable. If a Development Team member has a specialism in business analysis then he or she may be in a suitable position to assist.

@Ian and everyone else, the guide says hat the Product Owner may do this or have the Development Team do it, however, what if the team starts asking the scrum master to write stories. How can a scrum master prevent this and how can it (if this is an anti-pattern) be rectified if it already exists? I believe the primary reason the team feels this way is because they believe the scrum master needs to be kept busy.

If the scrum master has repeatedly quoted these lines from the scrum guide, explained to the BSA's, the PO and discussed with a functional manager but no one pays heed to the scrum master, is there any other alternate way to correct this behavior other than accepting it, leaving the organization or escalating further?

In the above context, I've seen many companies mentioning in their job descriptions, that a scrum master should be a delivery manager or should track milestones, should communicate progress etc. To me these are aspects of a PM. In the community's opinion, are these acceptable when considering jobs or while being in the role of a full time scrum master?

If an organization recruits a Scrum Master into a position through which the role becomes compromised, then it may be best to escalate. The expected outcomes from a Scrum implementation are unlikely to occur and stakeholders ought to be informed.

My general advice in such situations is to find out who wants Scrum and why. If this is unclear, then expectations should be set accordingly. Scrum terms of reference should be avoided until such time as sponsorship for the framework may be in place. This is important for transparency. The gap between the Scrum Master role and a so-called Delivery Manager might need to be highlighted, for example.

however, what if the team starts asking the scrum master to write stories.

If the Scrum Master has discovered new requirements, shouldn't he write up a PBI? What good would it bring to hold back on it? Many Scrum Masters come from a development background and occasionally that past may enable them to see something ;-)

I believe the primary reason the team feels this way is because they believe the scrum master needs to be kept busy.

Is the Scrum Master busy or not? If he is, he might try to create greater transparency over what he does in order to avoid this misunderstanding.

If the scrum master has repeatedly quoted these lines from the scrum guide, explained to the BSA's, the PO and discussed with a functional manager but no one pays heed to the scrum master, is there any other alternate way to correct this behavior other than accepting it, leaving the organization or escalating further?

Did the Scrum Master try to create transparency over what negative effects he experiences because of this? Hitting somebody over the head with the Scrum Guide has seldom helped anyone.

however, what if the team starts asking the scrum master to write stories.

If the Scrum Master has discovered new requirements, shouldn't he write up a PBI? What good would it bring to hold back on it? Many Scrum Masters come from a development background and occasionally that past may enable them to see something ;-)

IF, the scrum master gets a requirement, in my opinion, it is fine, however, what if the expectation of the team is that the scrum master is the main person to add/write stories to the backlog?

How does a scrum master create transparency over the negative effects, when the team perceives writing stories as a waste of their time (an impediment) 95% of their time. Inspite of coaching the team the reason for writing stories, the team still wants to adopt a template format for every work that comes, to save time. Again another clear indication of their reluctance to take the time to write meaningful stories. The problem essentially is that the BA's have elicited the requirements, but they wait till a refinement session or they email the details of the PBI/story to the scrum master, asking the scrum master to add it to the backlog. The team is aggressive, like a bunch of stubborn unruly kids who just want to get their way, who have this feeling that their untouchable because of management support, therefore the victim is the scrum master. What can be done to address this?

The problem essentially is that the BA's have elicited the requirements, but they wait till a refinement session or they email the details of the PBI/story to the scrum master, asking the scrum master to add it to the backlog. 

What does the Product Owner think about this?

however, what if the team starts asking the scrum master to write stories.

From the Scrum Guide

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

I will remind you that Scrum Guide also states that that the Product Backlog is the responsibility of the PO. This statement follows the discussion on that.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

Is the Scrum Master part of the Development Team according to the Scrum Guide?  Again from the Guide

The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

So, I would coach the team that based on all of that, the Scrum Master is not (for lack of a better word) eligible to write user stories that go to the Product Backlog. The Scrum Master can only participate in the Sprint Backlog. 

It sort of creates a conflict of interest since the Scrum Master's primary responsibility is to help the Scrum Team and the overall organization understand and appreciate the Scrum framework. 

Yeah, I know I'm being a bit academic and completely ignoring reality.  But if they understand the academics, it makes it a lot easier for them to apply reality to the premise.  

But as with all things Scrum, in the end the Scrum Team needs to determine what is the best way to apply process within the framework. You are part of that team as Scrum Master.  Honor the Scrum Values and have frank, open conversations with the team to determine the right way to do this, not the easiest way.

The problem essentially is that the BA's have elicited the requirements, but they wait till a refinement session or they email the details of the PBI/story to the scrum master, asking the scrum master to add it to the backlog. 

What does the Product Owner think about this?

In my team, the PO is also the BSA(the most experienced and tenured), and then there are just BSA's, a management decision in my organization.

The PO/BSA in my team, is one of those untouchables (because of management support/favoritism), does not like being coached, does not care about scrum or agile as long as the work gets done, but does not write a single user story. The just BSA's end up being the assistants of this PO/BSA person and they too think its the Scrum Master who should be adding/deleting stories. In spite of making humble requests to atleast come prepared with stories for the refinement, nobody cares.

As a scrum master in such a situation, talking about the scrum guide is the last thing that's going to help, but keeping hopes strong, whenever possible coaching is provided only to make minor to no change.

@Daniel Wilhite

But as with all things Scrum, in the end the Scrum Team needs to determine what is the best way to apply process within the framework. You are part of that team as Scrum Master. 

If the team decides that it is the Scrum Master who should write stories, then what's the need for a scrum guide. Is there any form of authority the scrum master can exercise or do we as scrum masters take the brunt of bad behavior?

@Steve  Based on the the principle of a self-managed team, if the team agrees then you do what they agree. 

Now let me put a little realism to this by taking off my Scrum Master/Agile Coach hat for a bit.  Hopefully this doesn't get me banned from the forums.  :)

Part of our job is to help people understand and appreciate the principles and values of Scrum.  Sometimes that means you have to let a team fail in order to learn.  So......

If the team feels that having the Scrum Master write all of the stories is the right thing to do, what is to stop you from helping them learn why that is not a good idea? I'm not implying that you intentionally cause problems.  But if you were to start writing stories based on your limited knowledge of the problem such that they had to spend significant amount of time refining the stories do you think that they might decide the decision was wrong and revisit it to come up with a better solution? As a Scrum Master your area of focus does not include the business problems being solved or the technology used to solve the problems.  You are focused on the ability of the team to be high performing and agile based on the use of the Scrum framework.  I can easily see how you would have limited knowledge to write stories or could easily misunderstand the information that is being given to you. 

Yeah, I went there.  Please don't hold it against me in the future. 

I'm actually with you, Daniel. PReaching the Scrum Guide usually doesn't make people appreciate why something might be a bad idea (after all, just because something goes against the Scrum Guide, it doesn't necessarily mean it is a bad idea). And so, sometimes a Scrum Master's best option is to let an idea play out and make the problems that arise transparent. It's important to not leave out that last bit.

If problems arise by the SM writing PBIs (and there's a good chance, that problems will indeed arise), then make them visible. Make their impact visible and discuss whether someone else (perhabs someone closer to the stakeholders) wouldn't be more suited to writing the User Stories.

"The team is aggressive, like a bunch of stubborn unruly kids who just want to get their way, who have this feeling that their untouchable because of management support, therefore the victim is the scrum master."

"The PO/BSA in my team, is one of those untouchables (because of management support/favoritism), does not like being coached, does not care about scrum or agile as long as the work gets done, but does not write a single user story. The just BSA's end up being the assistants of this PO/BSA person and they too think its the Scrum Master who should be adding/deleting stories. In spite of making humble requests to atleast come prepared with stories for the refinement, nobody cares."

Steve, I'm sorry to say, but I think you'd be better off in a new position. The culture/mindset in your current company is a very dangeous one. If people (PO, BSA, developers, QAs, etc) do not know (at this advanced stage of their career) that there has to be a continous conversation driven by the business representatives (PO, BSA, BA, whatever) and the development team, nor do they want to learn, it means they are acting in bad faith.

Now, I don't know how difficult/easy it would be for you to find a new job in your city (the smaller the city, the harder), but I would encourage you to reduce stress in your professional life.

"If the team decides that it is the Scrum Master who should write stories, then what's the need for a scrum guide. Is there any form of authority the scrum master can exercise or do we as scrum masters take the brunt of bad behavior?"

We're not working in a dictatorship. No one should decide over someone else's head. If the team decides (wow, what a feat!) and you disagree (for very good reasons I should add), then another way has to be found. In Scrum teams (or any form of modern teams for that matter), decisions should be reached either by consensus, or, where not possible, by compromise. So, rather than authority, you should have cooperation.

My advice would be as follows:

• start documenting all the pain points
• start looking for a new job
• explain to prospective employers why you're looking for a new job (can show them the doc - of course, nothing confidential)
• off you go to a new role

because I don't find this scenario sustainable.

@Julian Bayer

I'm actually with you, Daniel. PReaching the Scrum Guide usually doesn't make people appreciate why something might be a bad idea (after all, just because something goes against the Scrum Guide, it doesn't necessarily mean it is a bad idea). And so, sometimes a Scrum Master's best option is to let an idea play out and make the problems that arise transparent. It's important to not leave out that last bit.

If problems arise by the SM writing PBIs (and there's a good chance, that problems will indeed arise), then make them visible. Make their impact visible and discuss whether someone else (perhabs someone closer to the stakeholders) wouldn't be more suited to writing the User Stories.

I agree that preaching the scrum guide in a manner that prevents the team from understanding the crux is not helpful, however, some of the problems that I've faced because the team hasn't even bothered to read the scrum guide could be avoided if they understood atleast their roles and the purpose of the various ceremonies. Their illiteracy and lack of understanding of the scrum guide results in problems such as:

1. Team expects the scrum master to update the board (if you are using an electronic dashboard, like many of us probably are ex: JIRA, Version One) The why is in the scrum guide - Transparency.

2. Team expects the scrum master to add/delete/update blockers. Even something as simple as this, the scrum master has to do. Why does the team not understand that this is for the purpose of everyone, again to maintain Transparency.

3. Team expects the scrum master to be technically competent, manage timelines, milestones, be aware of every detail of the project etc. This puts a lot of stress on one individual especially if the team handles many projects and if some of them are very large and add to it, some projects still operate in waterfall. Team does not understand that the role of a scrum master is that of a coach, a driver of change, not be the servant or the stress buster of the team. Team does not even understand how their role contributes what the boundaries of responsibility are etc. For ex: the lack of awareness of the scrum guide and the role of a PO is why my manager and team believe that I, the scrum master should be the one maintaining the backlog.

4. Team finds no difference between planning and refinement and requests the scrum master to merge or eliminate one of them. Team does not want to refine on a daily basis. When coached about why we need to have a planning and refinement session separately, the lack of understanding cause of unproductive conflicts.

5. Use of story points: The team doesn't understand why this is used, uses it incorrectly. I've seen people still making a fuss over story points being reduced. I've seen people assign points like they were playing a video game to acquire points, like these points would earn them an extra dollar. Really??! Scrum doesn't say use story points. Why not use throughput as a metric instead? reduces the unnecessary hassle of these numbers that most people seem to be stuck on.

These are some of the thoughts/opinions I have that I have written, its not an exhaustive list but it all boils down to, how much we understand scrum. Preaching may not be the solution but if one doesn't have to quote the scrum guide to others, the others or the team have to be pro-active and read this by themselves to initiate a productive discussion. In my opinion over a span of years, my understanding and appreciation for the scrum guide has changed quite a bit but it all started with having read it once, then twice and then over and over again and seeking answers if something isn't clear. How many in our teams actually do this? Most likely none (I speak only based on my experience) Forget preaching, mentioning that there is a scrum guide is useless if the team has no motivation or interest to try something new or to change.

I think the topic got diverted a bit.

I have read your replies and my sincere thanks for your valuable time. Really appreciate it.