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?
- 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:
- Revealing to PO that writing user stories is a more clear, concise and ultimately valuable way to express a requirement for product change and
- 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 ;).
The very simple answer is;
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.
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.