Vague Backlog

Why did the CTO decide whether or not there was value in continuing with product development, rather than the Product Owner?

Our backlog consists of epics approximately as vague as "As customer, I want to know how to use [the product] better so that I can be better at using [the product]."

We, as a scrum team, during our meetings, tried to turn them into a concrete backlog. This seemed fine, but after a couple sprints, the CTO came to a Review and essentially scrapped our work, saying that we should have pursued a less robust solution.

How did you turn such a vague story into backlog items without more input from the PO or stakeholders? Why would it seem fine to be working off such vague information? That's like going to McDonald's and saying "As a customer, I want something to eat, so I'm no longer hungry" and expecting to get something you actually want. Are you surprised the CTO scrapped the work performed towards something is not measurable based off of relative expectations? "Better" is a relative term that is different for each person so how can you put a definition of done on something being "better"?

As a Scrum Master, what should I have done differently? What can I do to improve our expected outcome?

Work with the PO to get more details and groom the backlog to something that is easily understandable and transparent. Work with the Dev Team to not begin work on a story that is clearly not Ready to be worked on; picking items that are not in a Ready state is an epic waste of time and resources. Do self-inspection on a deeper level.

My bias is that I think that the Product Owner failed to adequately convey to the Devteam what the stakeholders meant by these epics.

All due respect, I think you should look at yourself for this failure; not in full but at least to recognize you contributed to the failure. If there is more information that you have not shared, that may change this assumption but here is why I feel this way:

1. The Dev Team selected backlog items that were not deemed as "Ready" for selection in Planning (Scrum Guide 2017, pg 15). You should have spoken up to remind them that they should not be selecting items that are not ready because otherwise creating a Done increment is virtually impossible.

2. The Product Owner didn't know or care about Backlog Management. This is a major service that the SM is responsible for to the PO (Scrum Guide 2017, Pg 8). 

3. You're not instilling an atmosphere of teamwork as evidenced by your blaming the failure on the PO. If 1 aspect of the Scrum Team fails, the entire team fails. The Scrum Master is responsible for helping everyone understand scrum theory, practices, rules, and values (Scrum Guide 2017, Pg 7). 

I'm sorry if that is hard to swallow but that's just based off the info you provided, and you did ask what you should do differently.

We, as a scrum team, during our meetings, tried to turn them into a concrete backlog.

Based on the Scrum Guide, "The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master". Therefore I deduce that you, PO and dev team together added details to the story until it became ready, and only then did you implement it. Unfortunately, the end result did not receive positive feedback from one of major stakeholders.

To me it sounds like your PO "failed" this time, but well, we should all learn from experience (empiricism). Hopefully by now he/she understands that maybe you should refine stories even earlier, and then actually discuss them with the stakeholders even before implementation, so that time is not wasted even more. I am not willing to say that this was SM's fault, as it could have been difficult to predict. However now your Scrum Team has learnt something, and not that PO is bad, but that more communication with stakeholders is required before the sprint starts.

+1 Filip

I didn't mean for my comments to put full blame on Paul as the SM. However, when stuff like this happens it is kind of hard to say that the failure was not shared. People are too quick to point a finger at 1 person that caused the problem but if we are team-based then the team as a whole failed. Even if it was a case where it truly boiled down to 1 person dropping the ball, there is always a way to improve as a team. Better transparency, better communication, better teamwork overall. Failure is not a bad thing though, failure is a great thing because typically you learn and grow at an exponential rate through failure. 

Sniffs like a Product Owner that needs training. 

"My bias is that I think that the Product Owner failed to adequately convey to the Devteam what the stakeholders meant by these epics." . My comment here to you is you have identified biggest part of the problem and you really need to work hand in hand with this Product Owner.Probably not their fault I'd only assume they were thrown into the role like a lot  of them are. Part of your role bro you need to coach this PO.

"the CTO came to a Review and essentially scrapped our work, saying that we should have pursued a less robust solution." This one bothers me but he is the boss so what are you to do. Sounds again like I said to another person this is your Opportunity to reset and coach mentor folks  at multiple levels which can be hard to do. 

Good luck.

Trying to turn vague epics into concrete backlog and then deliver can be the work of a team with a lot of 'courage' and 'motivation'....great values but unfortuately, there would be a lot of assumptions around what is the requirement and there is less likeliness of value being delivered

If such effort happens more out of fear that raising concerns on the vagueness of the requirements is not likely to be received well by the PO or stakeholders that means more understanding needs to prevail within and outside the scrum team that without clear requirements/Ready backlog, value can't be delivered

You and the Product Owner need to own the task of deriving the customer needs first. There are several agile techniques for this. As a Scrum master you have to learn (if needed) and teach and assist the PO in this initial activity. Once the needs are clear we can then articulate them in a way that the developers can understand and engage business (customers, end users) with further clarifications to further clarify them into consumable Requirements (user stories , Technical requirements, etc) following the INVEST principles.

https://reqtest.com/requirements-blog/5-essential-agile-techniques-to-i…

Under these circumstances I am particularly a fan of stakeholder interviews (surveys) combined with prototyping. 

https://reqtest.com/requirements-blog/how-to-use-interviews-to-gather-r…

The basic template looks close to this: (These can easily transform into well defined personas)

• Name:
• Company / Department:
• Title / Role:
• Primary responsibility:
• What tasks are you responsible for completing?
• To whom are you responsible for performing these tasks?
• What problems prevent you from performing your duties?

The Tasks and problems will make the meat of WHAT the product is FOR. Once you get few pointers regarding WHAT the product is supposed to do and who are its primary audiences, it's a matter of time for the product backlog to grow. But even one detailed enough need is good enough for the developers to start prototyping and engaging the stakeholders in the discussion to figure out "WHAT's NEXT?"

In your case (if its really true!) you seem to be trying to figure out HOW to use a product ! ("As customer, I want to know how to use [the product] better so that I can be better at using [the product].") before asking, WHAT is the product meant to do and whose problems is it to solve, whose daily tasks is it to make better or easier? And therefore ask them (through interviews/survey) what those activities are that are anticipated to become better because of this product.

Thank you all for your feedback. I will look into the resources you have mentioned.

Curtis Slough Your directness is helpful. I should have explicitly stated that, even if it is the PO falling short in some respect, I see it also as my failure as a Scrum Master to instill in him the motivation and the knowledge necessary to perform the duties of a PO. We did work as a team including the PO when we tried to create specific stories for the epics. Unfortunately, when he was asked questions about specifics, he would usually either just speculate with us, or say that he would have to get back to us later. So the pressure to create a sprint's worth of work at our meetings in spite of vagueness led to a lot of stories based on speculation.

Uma-Venkata Ratna-Kumar Lekkala Thank you for the detailed advice regarding gathering customer needs. I have tried to express to the PO my concern and work with him, but I am unsure of how effective I am being. This information will help. Regarding WHAT or HOW: the words are kind of confused in this case as the user story referred to "the product" which was not what our team is building. The user's "product" already exists; our team has been tasked with making a suite of features which will, among other things, help the customer better understand "the product".

The user's "product" already exists; our team has been tasked with making a suite of features which will, among other things, help the customer better understand "the product".

So you need to find out what their most common questions were and what parts of the product are most confusing for them to use. You have to work with PO to mainly gather this information. Have workshops with them to use the product together and listen to what aspects they have complaints about. That gives the initial scope of what high level aspects should be addressed in your features.

Also, your situation reminds me of a time where we worked on a guided UI as a way to introducing and explaining functionality and how to use the product to the user. This is somewhat like the feature discovery that you see with each new release of most of the cloud applications or mobile apps, where the app says " Hey , now you can do this", "Are you sure you want to submit this application without a preferred vendor (link to where the user can select preferred vendor)? I don't know much about the business domain of your product but I believe you can start with clarifying the existing app  and even adding a simple button called "Report problem with this product" and start capturing what they report into your backlog.

Paul, you made it even clear that your backlog's guru is going to be your end user :) All your effort should be to start engaging them and ask them what their main concerns are.