First time scrummaster - need to create product backlog and set up work

Question

I am certified scrum master but never practiced until tomorrow when I have been appointed as a ScrumMaster to a pilot initiative in the company to implement scrum in a team of non-software and non project but daily activity. I let you imagine all the politics around this decision.

The work will start on 1st of August, and the product owner has set up a meeting tomorrow to create the product backlog with me and another person, which will not be part of the team.

My questions:

• Who should propose the structure of the product backlog tomorrow (me or the PO)?
• Should we create directly user stories with the product owner?
• I have a one hour meeting, and in my understanding is that I need more than that? what is your suggestion on how to proceed?

I know all the theory but I miss the very practical steps to start.

Here is more information:

• Department: product development (non IT products).
• Team: 7 people.
• Product owner: is the manager of the department (the 7 people in the team are his team).
• ScrumMaster: I do not belong to the team nor to the department; I am working as staff function.
• Beginning of the work: 1st of August (but as you see in the question the PO wants to create the product backlog with me tomorrow (45 days in advance).
• Company: 100 years old, 25k employees, always used Waterfall methodology only 3-4 scrum initiatives ongoing in small IT projects (budget less than 500k €).

Answer 1

Agile and Scrum are based on collaboration and teamwork

If it is "non project but daily activity" Scrum is not a suitable process for that. You should consider using Kanban. However, looks like you all have decided to use Scrum. So, I will answer the rest of your questions based on Scrum.

Who should propose the structure of the product backlog tomorrow (me or the PO)?

Unfortunately you seem to be starting on the wrong foot. Agile and Scrum are based on collaboration and teamwork. You should approach this with an open mindset of putting your heads together to come up with the best solution.

Should we create directly user stories with the Product owner?

I suggest that your first session should be to articulate the vision. The team must develop a shared understanding of where you are going (what product) and why you are going there (business benefits) before you jump into the details of how to get there (product backlog). Take a look at the Product Vision Board from Roman Pichler for an example.

I have a one hour meeting and in my understanding I need more than that? what is your suggestion on how to proceed?

My suggestion for this question is the same as the one for your first question. Don't think in terms of what you need. Think in terms of what the work needs. If the work needs more time, at the end of the hour you all can agree to meet again.

I do not belong to the team

You now do. As soon as you were appointed as the Scrum Master of the team you have become a full-fledged member of the team. Get started with this mindset and you will be a more effective Scrum Master.

Answer 2

Ashok has some really solid suggestions here. I want to riff off those a little to provide some context:

Kanban vs . Scrum: If as you say, work is done daily, is it also "shipped" daily? For example, if you're project is fixing defects reported by customers, then they come in daily and get assigned daily and there is no release vehicle. Scrum will fail for this almost guaranteed. Kanban is the better choice. It doesn't have a time box sprint. Instead it has a backlog and Work In Progress limits (WIP). Work is taken from the top of the backlog and worked until done, then "shipped".

You can still be the Scrum Master and still call it "Scrum" to prevent management issues. Just set your iterations to one day and have your standup include pulling from the backlog. Part of your job is to both give the team guide rails and protect them from management so they can do their jobs.

If you have to go with Scrum, then go for a one week iteration. You'll have less chance of failure from changing sprint commits.

Product Owner Planning Meeting: As Ashok says, and you are concerned about, this is very early and it is not including the people doing the work. That's okay, work with it. A product owner needs to come up with their vision at some point. The product owner does own the backlog ultimately. They just have to ensure the team can execute on the backlog.

Work with them to try and get an Epic level flow of what they want to do. Then start early coaching that for the best success you should setup regular backlog grooming sessions with the team doing the work and (if you go with Scrum, not my recommendation) sprint planning at the start of an iteration.

One thing to focus on is the "Why" or "So That" part of the user stories. Try and steer your PO from making technology decisions "will use Perl" as that needs to be the development teams job.

Best of luck and come on back with more questions, we're here to help.