I am currently playing a scrum master role in the project. Because the PO refuses to write user stories - I have to do it myself, but this flow has led to specification breakdown and scope creep many times. Moreover, I can't focus on other important stuff. I tried to explain numerous times that writing and prioritizing User stories is specifically PO prerogative. Any suggestions for this case?

  • Sounds like an anecdote. Commented Feb 1, 2017 at 7:59
  • 1
    Does the PO give input into what should be created in some other way or does he leave it completely to the team what product is being built? Commented Feb 1, 2017 at 11:28
  • I have come across this situation whereby PO's don't have the technical skill, experience or bandwidth to write user stories. It's not as uncommon as some might think especially if organisations have dedicated BA's which become PO proxies. Commented Feb 1, 2017 at 13:33
  • What do you mean by "I have to"? Your or project manager is forcing you to write stories?
    – Vlad
    Commented Feb 2, 2017 at 9:52

4 Answers 4



  • You're not wrong for writing the stories; it may be wrong in continuing to do so without change
  • Scrum doesn't say PO has got to write product backlog items or that they be user stories
  • Continuing serving, but do so by showing the cost of bad practice
  • Evidence, evidence, evidence.
  • For more good points, check out Venture2099's answer below for other very good things to consider.

nvoigt: Sorry to be blunt but this is not a project management question, this is a workplace question.

I agree, but you're right to ask it here since it impacts at least two, clearly defined SM responsibilities in the Scrum guide:

  • Finding techniques for effective Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;

nvoigt: As long as you do it for him, he found the perfect idiot.

You're NOT an idiot for doing it for him, you were serving him and the Dev team. If you suspect he and the Development team would be better served by him writing the PBI's more often and using the user story format, reveal the reasons and the data that substantiates your claim. Call him to be accountable for choosing a less valuable, more wasteful approach that exposes the organization to unacceptable risk. Do so with evidence.

Data you could gather would be things like:

  • Amount of rework (misinterpreted work requirement, scrapped approaches, miscommunications)
  • User/stakeholder satisfaction with delivered work
  • Defects discovered
  • Rate of value completed
  • Rate of work items completed
  • Cost of development team time (hour / day / sprint)

Carefully observe and involve the effect of the PO's practices on the development team. They time is very expensive to the org, and even an hour here or there spread across a six developer team can be very costly when summed over a Sprint.

There may be two difficulties here:

  1. Revealing to PO that writing user stories is a more clear, concise and ultimately valuable way to express a requirement for product change and
  2. Forming a working agreement that finds the right balance of PBI writing between the PO, you and the Development team

Scrum does not mandate that the PO write the PBI's, only that he/she be responsible for it's availability, content and ordering. This PO may well be skirting his responsibilities. I encourage you to serve your team by leading empirically rather than emotionally here. Bonus: evidence tends to be more useful when going to someone's superior about their behavior, but let's hope it doesn't come to that ;).

  • Thats a great answer Jason...I would vote it above my own. Maybe incorporate my points into yours and this can be the definitive approach. Commented Feb 1, 2017 at 22:13
  • 1
    Scrum does not mandate that the PO write the PBI's, only that he/she be responsible for it's availability, content and ordering. Exactly this, +1. I don't discourage anyone in the team from writing user stories, but ultimately the PO has the final say. Forcing rules and regulations on roles in an agile team seems contrary to its goals, and can have an overall negative impact on the success of the methodology.
    – dKen
    Commented Feb 10, 2017 at 8:18
  • Don't agree with that. Writing stories is straight PO's responsibility Commented Mar 25, 2017 at 8:53
  • 1
    @RuslanDoronichev it sounds like you've been misinformed. Take a look at this section from the Scrum guide: scrumguides.org/scrum-guide.html#team-po It seems pretty clear that while the PO bears the responsibility, the Development Team or even others may do it on the PO's behalf. Commented Apr 17, 2017 at 19:57

The very simple answer is;

Short Term

Deliver the stories that are on the backlog and have been prioritized by the PO.

If that is 0 stories then it is 0 stories. I have seen this situation in enterprise organisations occur and I have seen Scrum Masters stick to their principles and allow the situation to escalate. It really depends on the environment you are working in and how Scrum is perceived.

If it was me, I would let the team deliver 0 stories or simply prioritise all of the engineering tasks they wish to do and include 0 feature stories.

Long Term

As Scrum Master you have a responsibility to educate and evangelize the Scrum framework to the business in which you are working.

The first action should be raise this issue within the Community of Practice / Centre of Excellence if one exists for Agile or Scrum within your organisations. If you have access to an Agile Coach then request support immediately to resolve the situation.

The next escalation is to articulate your concerns regarding the Scrum implementation to the Product Owner in written format and also cc in the Programme Manager in charge of the department or delivery. If no Programme Manager then simply escalate to the next highest authority.

Outline how Scrum delivers value through the framework and the steps you would like to take to resurrect the delivery of the project.

Lastly, start work on a syllabus of workshops and training material to outline the key aspects of Scrum. Run them on a regular cadence (weekly, fortnightly etc) and layer each workshop in a way that it builds on the principles of the one before it. You should be in full on coach mode by this point.

If the business do not support you then give serious thought to the precariousness of your position as Scrum Master in that particular organisation. If you are a contractor, dust of your liability insurance and begin to reach out to recruiters. It is unlikely that this situation will be resolved without someone leaving the project or at the very least asking for evidence from you that you have done the correct things.


From the moment the different roles of the Scrum Framework are no more respected, you can't really call it Scrum methodology anymore.

If you are defining the work breakdown by yourself, organizing the work for the team and removing impediments for them, it seems to me you are closer a project manager role than a scrum master.

Hence the added value of your PO is really questionable and actually results in endangering your project. You should try to solve amiably this issue with him, and if it fails, escale this issue to a higher authority.


Any suggestions for this case?

Sorry to be blunt but this is not a project management question, this is a workplace question. As long as you do it for him, he found the perfect idiot. Would you do my programming job as well, if I simply said I'm not doing it?

I'm not a big fan of the soft approach of you trying to teach your PO to do his job. He's paid for it, isn't he? You need to stop doing his job and start asking why he cannot do his job. Work with him on any issues that come up. If he has no solid explanation, have a one-on-one with the POs boss and ask him why the PO is not doing his job.

  • I cannot say I agree with this answer; although I understand the spirit of it. The role of PO can vary widely across the industry with numerous descriptors used for similar roles (Product Manager, Change Manager, Delivery Lead, Product Owner etc etc (insert your own 50+ examples). There may be a genuine case for the OP to explain Scrum and the roles within the framework. I would not go so far as to call the OP the perfect idiot since certain organisations have dysfunctional views of Scrum and require education and time to improve the culture. I doubt workplace.se have the Scrum awareness. Commented Feb 1, 2017 at 13:31
  • @Venture2099 However dysfunctional this company is, the simple truth is that only the POs boss can make him do something or explain that writing stories is not the POs job. Either way, it's the boss' decision. Please note that I called the OP the perfect idiot in case he is silently doing the POs job in addition to his own without asking the boss, not for asking this question or working for a boss not understanding scrum.
    – nvoigt
    Commented Feb 1, 2017 at 13:36
  • 1
    @nvoigt this answer does not seem to encourage practicing the Scrum values of either "courage" or "respect". Courage means doing the right thing and tackling the hard problem of teaching and coaching the PO to choose better ways of working with the Dev team. Respect is treating the PO like a capable, independent person who can see the error of his ways. Refusing to help or insisting on dragging the PO in front of his boss(es) seems overly rash and assumes the PO to be incapable or an opponent of improvement. Commented Feb 1, 2017 at 19:43
  • @jason.t.knight Maybe you missed the OPs sentence "I tried to explain numerous times". How many times do you think it's okay to show courage and respect before you involve someone with the power to influence the PO?
    – nvoigt
    Commented Feb 1, 2017 at 20:57
  • @nvoigt I didn't miss it, I just assumed that the OP is like me i.e. more prone to explain based on contents of Scrum guide than to demonstrate through data. It seems likely OP is new Scrum Master if he is just now encountering this issue and might be less confident taking an evidence-based approach to persuasion. Last, if OP has done so and evidence has failed to persuade the PO, then I recommended PO be take to task with superiors, but armed with data not accusations. The evidence based approach is more difficult but ultimately more courageous and respectful. Commented Feb 1, 2017 at 21:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.