How do you (developer) deal with unclear requirements and multiple acting POs? [closed]

Question

Here's another question trying to figure out how Scrum could/should work in real life. Here is a typical scenario I encounter:

Note: The term "Product Owner" is not used below. That is because the true "Product Owner" - the Product Manager in this case - does not make the final decisions. The DB Lead has final say on many things as he decides how the app interacts with the DB. QA has their own ideas on how things should look / work - and their ideas are entered as bugs and generally expected (by everyone) to be treated as such.

1. Product Manager writes a story like this "X User needs a page to do Y".
2. At the sprint planning meeting the story is added to the sprint backlog.
3. Some poor developer grabs (or is assigned) the story.
4. The developer asks the Product Manager "what do you want the page to be like".
5. Product Manager (if available) says, "Hmm, well, it needs to collect A, B, and C."
6. Developer starts working on his best guess as to what that should be like.
7. Developer tries to hook up the page to the Stored Proc and asks the DB lead some questions. DB lead says "Page also needs D and E. And shouldn't need B".
8. Developer makes changes and commits it.
9. QA says "I think E is confusing".
10. Developer has to wrangle around trying to get the QA, DB lead, and Product Manager to agree on what the final page should be.

My understanding (according to how we have been taught scrum) is that it's the developer's responsibility to flesh out the requirements for the page. In our environment, as illustrated above, this makes for a frustrating experience for the developer as well as a lot of wasted time for the developer while waiting to get all the powers that be to come to a unified decision about what the requirements are.

Sometimes it could take hours over multiple days to nail down the requirements for a 2 hour task! It's hard enough to get enough time with 1 person - even harder for 3!

I know it is anti-scrum, but it seems to me that the Product Manager, the DB Lead, and the QA team should meet before the Planning Meeting and hash out the details of the tasks to be added to the sprint. (Developers rarely have any input that is considered, and when we've tried to do this in meetings it could take a full day - not kidding - to hash out all of the details for all of the items in the backlog.)

Has anyone dealt with this? Any suggestions? I don't want to ramble on too long, so let me know if you need additional detail.

Thank you!

Answer 1

That is because the true "Product Owner" - the Product Manager in this case - does not make the final decisions.

And that is exactly your problem. Scrum says

The Product Owner is not a person, it is a role. Everyone can be the Product Owner.

If your product manager can't make these decisions, he's not the product owner IMHO. In that case find the person who can make these decisions, since this is your real product owner.

I, as the developer ("The Team" role in scrum) only need to find out how the product owner expects this feature to be. He is the owner, he explains to me how the page should look like and I will make it according to his description. The DB lead is not the product owner. QA is not the product owner. I made the page like the product owner wanted it to be and if DB lead or QA has a problem with that, they should talk to the product owner. Or actually the product owner should have talked to them in advance.

Also why haven't DB lead and QA been at the sprint planning meeting if they somehow serve at product owners, too? In that case they could have immediately shouted "objection", when the product manager said A, B and C. DB lead could have said he needs D and E, and B shouldn't be there. And QA could have said, they think E is confusing. As long as the people who finally have to approve my implementation after the sprint don't even agree on what they want to have, I will not touch this thing at all.

Answer 2

A couple of suggestions:

Context: "X User needs a page to do Y" is missing context. I like the framing "As an X I want do do Y so that I can Z". It's slightly different, but the Z part adds context on what the user is trying to accomplish.

Acceptance Criteria: You didn't mention acceptance criteria. The story should include a list of acceptance criteria to indicate when the story is done. I like the phrasing "Given X, When Y, Then Z" (e.g. "Given that the X user is logged in and has a positive bank balance, when he navigates to the Y page, then he sees a smiley face next to his balance". Usually, there will be a list of these acceptance criteria.

I think you'll find that the Product Manager, when forced to define acceptance criteria, will develop a better perspective on what exactly he/she is trying to accomplish with the story, and can convey it in more detail. Aside: I also find it helpful for the testers to review the acceptance criteria for testability issues.

What vs. How: It sounds like you are still wrangling during the iteration on what needs to get done. The negotiability notion in INVEST* story criteria is more geared towards how the story gets implemented. The what should already be defined before the story is added to the iteration.

*INVEST - Independent, Negotiable, Valuable, Estimable, Small, Testable