There was a recent discussion in the Agile and Lean Software Development group on LinkedIn asking about whose job it was to do various traditionally Product Owner tasks. The question is “Who’s job is to maintain the backlog, refine stories, writing acceptance criteria, etc.? Most of the projects don’t have a dedicated product owner so scrum master ends up doing that, is that ok?”
Take a moment to take that in and think about not only the immediate problem but the implications of such a question. The comments are all over the spectrum, ranging from insightful to helpful to downright insipid. This question though has three fundamental flaws that need to be addressed.
Not having a Product Owner
This is a huge problem. The Product Owner is the single most important role on a Scrum team. One of the comments stated, “Not having a Product Owner is like having a car without a steering wheel.” Exactly.
Lacking this critical role is a problem. How do you ensure you are delivering value, ensuring priority, and handling acceptance? It is true, that tech teams creating small tech solutions can do without a product owner. If they eat their own dog food they become defacto product owners. Other than that very specific and niche scenario, there really isn’t a good outcome of not having a product owner on the team.
Asking if it a solution is ok
This one may rub folks the wrong way, and I could easily be inferring something from the question that is not there, but, why are you asking if it is ok? Do you have an idea for a solution to the problem? Great! Try it. Inspect. Adapt. Rinse. Repeat. That is the entire strength of Agile: the quick feedback and ability to adjust when things work or when they don’t.
This may just be the bold mentality, but I am far more inclined to jump on out there and try it and see if the noodle sticks to the wall. Get your team onboard, excited even, about trying something new and let them help guide the ship. The team will be engaged and invested and you could end up with greatness.
Not understanding that Agile is a culture, not a doctrine or methodology
This one is the big one. This question implies a very real lack of understanding of what Agile is. Although I touched on this in the previous one, please understand: Agile is a culture of adaption and change. It is not a doctrine or methodology. Scrum, Kanban, XP, etc those are methodologies (barely in some cases), but they are not meant to be applied in a dogmatic way. The very real intent of Agile, change for good to focus on customer results, means that you cannot be dogmatic. You should be adapting all the time and by the mere fact of that adaptation, you will not be following any of the methodologies to the letter for long. And you shouldn’t. This is not PMI or ITIL, Agile is the excuse you are looking for to experiment.
So, what is the answer to the question?
The answer is to find what works for you. Do not get hung up on roles, who does what, etc. Does everyone remember that stories are meant to be collaborative? Product Owners are not responsible for writing stories, although they do the most. Not because they are “supposed to” but because they are best suited to the task.
Ask yourself that then. “With the resources I have, who or what group of team members is best suited to fulfill the need to writing stories and ensuring the acceptance criteria is of sufficient quality etc.?” It probably is not a single person, but a group of people. Who is responsible for delivering value? The team. Does the team need well-groomed stories to fulfill the primary responsibility for delivering value? Yes? Then guess who is responsible for the stories? The team.
Yes, the Product Owner is important to the team, but they are a member of the team, and the team, not a group of individuals, that is just a herd, the team is still responsible.
Be a team, not a herd, and together do what it takes to deliver value. Get better every sprint doing it, and you have your answer to whose responsibility it is to do anything.