4

In my scrum team, we basically don't have a vision for the product. Our product owner thinks she's writing user stories but they are really just high level epics. Breaking down those 'stories' ends us up with having to interact with dozens of different stakeholders in the business and gathering requirements for something we have no idea what it is!

My concern with doing this, is that stakeholders don't really know what they need. Each of them might give us conflicting information. Then, each of us on the development team might hold conflicting information and all hell breaks lose when we attempt to build the product.

I'm increasingly feeling that it's the sole responsibility of the product owner to engage all the stake holders, aggregate information they give and form a vision for the product; something it seems, is being farmed out to the development team instead.

Is it a good idea for us developers simply refuse to engage stakeholders? How can a Scrum team encourage the product owner to work with the team in breaking down the user stories?

  • 1
    Do you have a Scrum Master? One of the main jobs of the Scrum Master is to coach the team on how to work with Scrum, including helping the Project Owner to understand their role. – Barnaby Golden Jul 30 '16 at 7:20
4

First, when it comes to communication, Scrum is a framework, like any other Agile methodology, which encourages collaboration between business people and stakeholders. This is reflected in the 4th Agile Principle:

Business people and developers must work together daily throughout the project.

Thus, development teams should never refuse to work with stakeholders.

However, the development team shouldn't be solely responsible for breaking down epics into implementable user stories. This is the job of the entire Scrum team, which includes the product owner. While not an official Scrum event, the Backlog Refinement meeting is what many Scrum trainers recommend Scrum teams adopt. Michael James, CST, explains this in Scrum Training Series - The Backlog Refinement Meeting.

3

If your workplace is this disorganized then I highly doubt you have a right to "refuse" certain procedures. Chances are you'd be fired or let off the project.

My recommendation is as follow:

  1. Bring up your points on what is unclear and why it is unclear. Don't point fingers.
  2. If you can't bring up points and you are forced to work in such a environment, then consider leaving. There is really no way to go to upper management and "refuse" to do work they assigned you.
0

I think your only solution is to find a way to plug your Product Owner into a scenario where she can be challenged on her user stories effectively. Is she open to joining practice groups? Benchmarking with another similar company who has a mature Scrum setup? Your developers should be able to engage with the customer, but if you have no real product owner they'll have zero direction, so any customer contact is completely futile and may spread the view to the customer that your team doesn't know what it is doing.

What is she open to learning?

  • 1
    I think trying to hide that lack of direction through a lack of communication runs counter to our agile values. – Nathan Cooper Aug 3 '16 at 9:07
0

Ideally the Product Owner is the single point of reference for any questions about the stories. So no, ideally, devs shouldn't talk to stakeholders.

The reason for this is, as you say, two stake holders can have differing opinions and priorities. You need a single answer.

Having said that, talking to stakeholders when they give clear and united answers isn't a problem if the PO doesn't mind. So really I think you just need to be a bit more rigorous with the documentation of these questions.

  • Add the questions to the story/epic
  • Add the answers to the questions, with who said what when.

Then you only need to raise a problem when you get unanswered questions or answers that conflict. These you can kick back up the product owner for resolution.

0

You are not alone in this problem. Often times, individuals are placed in the role of Product Owner without understanding the role and its importance.

Much like the Sprint Goal, the product vision (provided by the Product Owner through collaboration with the customer) provides a common Focus for all involved: Scrum Team, customers, business stakeholders, etc.

It's good for the Product Owner to begin with epics. Further understanding can be shared during Product Backlog refinement with the Development Team. As a member of the Development Team, you want Product Backlog items with enough detail to complete the work and not necessarily a highly detailed specification.

If refinement is done well, many questions will surface before work on that item begins. Sometimes additional questions will arise during the Sprint Planning event. Another place where the Product Owner can provide these answers or make a decision that the item needs to be re-prioritized until further clarification from the customer can be gathered. The Product Owner is to be the one source of requirements for the Development Team

While Scrum does not prohibit the Development Team from interacting with the customer, the value of Focus should make one consider the amount of such activities and the effects.

The place to bring up these concerns is the Sprint Retrospective event. The behavior is affecting the Scrum Team's ability to deliver value.

Is The Scrum Guide being followed? Do have an absentee Product Owner? If there is no alternative, do what you can as a team and keep reiterating the impacts of the situation and possible solutions.

http://scrumguides.org/scrum-guide.html#team-po

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy