SCRUM - How do you (developer) deal with unclear requirements and multiple acting POs?

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

You probably don't need to meet before the planning meeting for everything, but only when conflicts are found. It's probably easiest to have a quick meeting with all stakeholders and make a decision everyone can agree on.

Just because you scrum, doesn't mean you shouldn't have smaller more targetted meetings afterward.

Answer 2

It is the developer's responsiblity to make sure that he fully understand what he needs to do in a givrn task. If some requirement is unclear you must ask for clearification until both the developer and his peers / manager fully understand what needs to be done.

You should ask questions such as "how would we define a successful executation of this task" or "how would the customer expect this to be" and so on.

A developer should make sure that he fully understand what he needs to do in the next cycle before the end of the iteration planning meeting. In case some requirment is still unclear it should be addressed in the SCRUM meeting as something that prevents you from reaching your objectives.

Answer 3

Some things I noticed...

1) You mentioned a developer pulls a User Story

Really it should be broken into tasks during planning.

2) You mention that it would take all day to hash things out.

Sprint planning can take a whole day. You'd be better off spending that time all at once and getting enough information to move forward in the right direction than spending so much time rehashing.

Answer 4

My suggestion would be to have the PO be the owner of the tasks in terms of deciding what is the expected behaviour. This may mean going through a dozen or more odd cases where the system being built to allow Y also has to do something in case Z is down or W is not responding in time, etc.

While it may be the developer's job to flesh out the details, this is merely asking the question to the proper person. It is for the PO to say that "Oh, I'm sorry, I do want D and E in there now," as part of the process is to handle changing requirements so that the key is on the outcome and not if 101 steps were done to get the product's new version ready for the end of the sprint.

Another option is to have a team lead or group manager, the manager of developers that should be separate from the project if in a big company, be a resource to go to where you could say, "I want to do D but need more specifics and can't seem to schedule a meeting with the PO," and hope that this person has better luck.

Answer 5

uh, wouldn't it be simpler to talk to all the stakeholders first, then design/implement the story?

EDIT: based on comments and a more careful reading of the original question, i think perhaps you have been calling your process 'agile' or 'scrum', but it really isn't. Based on your original points, here's what i think is going wrong [caveat: i am not all that familiar with scrum, but i have been using XP for several years]:

1. Product Manager writes a story like this "X User needs a page to do Y".

   • The product manager is not the customer, nor is he the developer. User stories should be written by the customer and the developer. So, this step is not XP/Agile, this is waterfall. If "User X" needs a page to do "Y", then you and User X must write the story about Y. Only then will both the developer and the user have a common understanding of the story, which is the whole point of user stories. The PM saying 'go write a page for user X to do Y' is not a story, it's a task. So, it looks like your team has fallen off the wagon from the get-go.

2. At the sprint planning meeting the story is added to the sprint backlog.

   • so now the sprint backlog is really just a list of tasks created by the PM. You are already hosed my friend, this is not an agile method, this is traditional project management masquerading as an agile method.

3. Some poor developer grabs (or is assigned) the story.

   • Let's see, since a story is a placeholder for a conversation, and the purpose of having the developer and customer write the story together is to provide a mutual understanding on which to base the conversation, then randomly assigning a story (which is really a PM task) to a developer who has not had this conversation is likewise not agile - this is mere task assignment, under the all-programmers-are-interchangable-cogs-in-the-machine assumption which is of course absurd

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."

   • once again, the PM is not the customer; who cares what the PM thinks about the page? What matters is what User X thinks about the page.

6. Developer starts working on his best guess as to what that should be like.

I'm going to stop now because I'm getting depressed. This is not agile, this is ridiculous:

• the customer is not involved in the story
• the developer is not involved in the story
• no developer-customer conversation occurs
• the PM is making things up
• random developers are being handed tasks made up by the PM

In what way is this supposed to be an Agile method? Calling it agile does not make it so - it's all about the principles of the method, not the terminology. No wonder the process is failing!

Answer 6

I haven't done scrum yet (although I've studied it and like it) but it seems to me that the PM isn't doing their job if the user story is really as barebones as you indicate. As to the practicalities of getting through your day: call one meeting with all 3 parties and hash through it together rather than trying to be a go-between.

Answer 7

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.

Yes and No.

Yes, if you can implement the task from start to finish yourself.

No, if your code interfaces with someone else's, or the user's I/O inter-hand-to-face for that matter, then you need an agreement on the specifications of the code/user interface. Most importantly, what can not be done, and how to work around it if necessary.

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.

I perfectly know what that's like! You don't happen to work at my place? :)

Here's a real world example that i've had to go through:

• Designer designs a UI page up-front. It's about displaying hierachical HTML pages and has buttons on top and to the right side, sort of like a tabbed dialog but with tabs on two sides. Mockup looks good and seems reasonable, no big deal issues. Accompanied with some detailed description of what this dialog can do etc. It seems as if everything is done and said.
• Designer actually gives me the task to implement the data structures for this into our database. Which is unusual but the scrum master has been informed. Still, communication was a bit tough for both of us because of a language barrier both in human language as well as the fact that he's a designer and i'm a programmer from a different pod.
• I work on implementing the tables in the databse and adding the UI for it to our DB frontend application. I make a few assumptions on minor issues as is usually the case with most tasks I get. I also adapt (normalize as good as i can) the data i've been given and told how it's used on the dialog so it fits best into the design of the DB frontend application. A few questions come up that i try to resolve because one of the design requirements would either explode exponentially (database) or become unusable in the frontend if i had done a regular denormalization. So i was opting to get buy-in for this, which i got but unfortunately, this turned out to be a major misunderstanding biting us later on.
• Next up, the programmer exporting the database has some questions. I answer them. I rework a few of the things so he has an easier time to export things, respectively we're working around some of the limitations of his work environment. Other issues just need clarification of the "unusual and confusing terminology" the designer used.
• A third programmer begins working on implementing the designer's UI mockup. Immediately some questions are raised. More tweaks are being done on the database tables. Suddenly i have committed to something i have a hard time implementing in the DB frontend application, but i was able to work around it. However, the DB exporter programmer has to rewrite some of the code as well, and he's not happy with the new data layout.
• Now we find out that there's been a major misunderstanding in part 1. I get another rework task to redo 50% of the work. Fortunately, no one has yet entered production data into the database, so i could scrap most of it. Still, the task has already taken 3 times as long as initially thought.
• Again, this goes to the exporter and UI programmer adding more time into it.
• Finally, someone starts entering production data into the DB frontend and doesn't know how to work with this. He finds himself communicating between two programmers: UI programmer and DB frontend programmer (me) who both have different views on the task. More rework is being done but most time is spent explaining how things work.

This is just a very condensed and small part of the story. Not an interesting read i assume, i can't give much details nor do i want to remember everything that happened. What were the major problems in this example?

• Designer unfamiliar with DB and frontend
• DB Programmer unfamiliar with UI design
• Designer and DB programmer have misunderstandings, each making their own assumptions based on their experiences
• concessions are made in the technical design to accomodate for limitations of the DB frontend and the DB exporter
• avoiding to write costum code in the DB frontend and exporter as this would have blown the initial task estimation big time
• Because of constant requirements and implementation changes, there has been confusion all along. Amplified by the fact that we didn't work on this together at the same time, but one at a time with days or even weeks in between.

But the biggest issues of all: Inter-Pod communication. Everyone was used to working inside their pod and since people knew each other and what they are doing, not everything needs to be explained or written down in excrutiating detail. However, once the talking with other pod members started no one expected communication to be so difficult. People wanted to know seemingly obvious things in great detail. Some issues just didn't "stick" and came up over and over again. It was frustrating for everyone involved, which further limited the effectiveness of the communication.

What i am getting at: communication is key and once other pods that don't normally work together are involved, the communication overhead can be quadrupled. If you are not prepared for this it can lead to frustration, demotivation, lackluster implementation, and so on.

The more people are used to working with each other, the less they need to communicate. The reverse is true doubly so. Be aware of that and plan ahead.

Answer 8

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 9

The problem is not "Scrum in conflict with the real world". The problem is "I expect good things from Scrum in spite of other issues."

The root cause of your problems is that someone doesn't want to wait for stakeholders. Everything else is a workaround to this problem. Getting the developer started early with an incomplete story is causing the unpleasant dance between Developer, DBA's and QA. And getting started early is -- well -- not helping.

DBA's and QA couldn't call the shots if you had a solid, consistent user story. You could trump their input, if only you had the details.

You can't blame your current process (or Scrum in general) because you don't have solid user stories from your stakeholders.

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!

You make this sound like a bad thing. 2 days of conversation to nail down the requirements followed by two hours of technical work is a good ratio. That indicates, care and thought. That shows that you are doing the right thing.

Be careful of imposing make-work tasks that are designed to keep the developer busy so that he doesn't start running with scissors.

If it takes days to get the story right, then, well, what can I say? It takes days. Spend the days. That's what it takes.

Don't cuss out the developer because they're not coding. The first one to start coding loses.

Solution

When PO's can't envision a future state empowered by software, you need to introduce someone into the process who is a technology visionary. Sometimes they call this role a "Business Analyst". Some Business Analysts are closet designers and architects. Fire them. Some Business Analysts can help the PO crystallize a vision of a new way of working, empowered by new software. Reward them.

Answer 10

My team faces this problem all the time. We get a very broad user stories and are asked to deliver a couple of them within a 2-week iteration. We spend a week talking to our POs (we work across sites) fleshing out the details of one user story (if we are lucky, we can do two), and write our own user stories so that function/acceptance tests can be written against them. Then we start estimating the complexities of each of them and give a commitment on how many we can realistically hope to finish within the remaining one week.

Invariably, one broad user story get broken down into at least 6 or 7 finer user stories. This gives us a grip on how complex the broader user story really is and by doing this repeatedly we hope to communicate to our POs that they need to give us finer user stories, but so far we haven't had much success.

As S.Lott said in his answer, if you get unclear or too high-level user stories, you have to play the role of a business analyst to bridge the gap between the POs and the dev team.

Answer 11

It sounds like you are confusing Scrum and XP's Planning Game. Of course you can adjust the methodologies according to your organization's needs, but even as an XP Planning Game, I think it's missing the point.

The basic premise of the Planning Game or Sprint Planning is that the Developers or "pigs" (including DB Lead and QA) are giving up the right specify "what" and "when" of the product to the Stakeholders or "chickens" (Product Manager). So it certainly is not "anti-Scrum" that those who is in the position of specifying the "what" meet beforehand to discuss the details or priorities to bring to the table.

As I answered here, the details are filled out in Sprint backlog. This could be in the form of User Stories, but Sprint Backlog cuts more into design and tasks.

Answer 12

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