As a developer, what can I do about bad/lack of requirements from the product owner?

Question

I’m a junior developer at a small SaaS company following a variation on Scrum. I have observed that stories often reach my team before the business requirements are fully fleshed out. The development team often brings tasks to near-completion only to learn that the product owner has just discovered a new, crucial requirement that forces us to rework our implementation. Other times, developers discover that recently deployed changes had first and second order effects on the business that were unanticipated (and unwanted) by the product owner and stakeholders that requested them. These revelations typically trigger a series of code "fixes" and various other kinds of remedies.

What, if anything, can I do to make sure that requirements are well-thought out before development starts and minimize wasted development effort?

Answer 1

Ask questions.

In Scrum, the most natural opportunity for such conversations are backlog grooming meetings, where new or changed backlog items are estimated.

For instance if you're playing planning poker, your deck might contain the ? card. Play it whenever requirements are not precise enough for estimation, and ask follow-up questions. Likewise, if different people give wildly different estimates because they understood requirements differently, they should ask the PO for clarification.

Questions that do not affect implementation effort can be asked during the sprint (that's why the PO should be available for questions).

If in spite of your questions the PO continues to waver back and forth, that is his responsibility, not yours. In that case, make sure to make the wasted development time transparent by not accepting big requirement changes during the sprint, but ask the PO to write new stories for the changes. That way, the PO and any stakeholder reading the backlog can see that there is a requirement gathering problem, which increases the chances that it can be addressed.

Answer 2

Nothing, except do a good job, get promoted, become the product owner, and then produce well-thought out requirements.

To some degree this is what scrum is supposed to handle: The reality that some people don't know what they want until you show them something, and then they know what they want changed. That's why you do tiny tasks where changing them is not too much effort.

If there are side effects "that were unanticipated by product owner and stake holders", such side effects are often anticipated by good developers, and a good product owner would listen to feedback from developers. Bad product owners don't; this may also be a cultural problem.

Answer 3

One thing you can do is try to shorten your rejection cycle. It's not clear from your question where the problems occur. But, for a specific example, Jakob Nielsen (https://www.nngroup.com/) [disclaimer: no relation, no benefit accrues to me] has published a newsletter for more than 10 years about user experience testing and UX design. He offers specific advice on how to prototype user interfaces, and how to do UX testing "on the cheap."

It might be the case that sitting down with someone from the user side and going through a prototype that is mocked up with a paper document and some cut out paper buttons and menus could save you considerable design/rework effort.

There are similar modeling options in other aspects of your software. For example, if your problems spring from accounting issues, maybe a primitive model built in a spreadsheet could make things go more smoothly. ("Oh, we have to apply sales tax? Okay, let's add that in at line 22.")

Honestly, it sounds like you guys are doing things slightly wrong, because it shouldn't be possible to get to the situation you describe. If your system owner is laying down requirements, you need to back them off and work more on user stories. If there's a user story, and someone tries to change it, THEN you challenge them: how could this user story have changed? Is this really a change to the user story, or is this a new user story with a slightly different circumstance?

I can imagine something like logging or auditing showing up late, where you spoke to the end users, got their stories straight, and didn't realize that every order entered required an audit entry. But invisible requirements are invisible. They won't change the user story, so it shouldn't be too hard to add those features.

Answer 4

First of all, you're not alone, and in a way being able to adapt your work when new elements pop up is exactly one of the reasons why framework like Scrum are used. That said, you have several ways to mitigate the problem:

• Work on a Definition of Ready, agree with the PO on the definition of a minimum checklist a task or story needs to comply with in order to be eligible for work in the backlog. This may include something like fleshing out a sufficient number of Functional test cases. This naturally forces to think upfront of all the necessary acceptance criteria. If the task does not have enough elements to scope its perimeter at the beginning of the iteration it should not get into the iteration backlog.

• Take time to analyze things before they get into your backlog, you may have enough experience or elements to pinpoint issues in time to fix them.

• Report any inconsistency immediately to the PO, and keep track of them all along the project, so that you can have a discussion backed by some data on how to reduce them.

As for the unknown unknowns, well there's not much you can do upfront, but you could structure your work in a different way

PS

I'm quite baffled by the obliviousness of some answers. "Nothing can be done" is the worst way of being professional in such cases.

Answer 5

The development team often brings tasks to near-completion only to learn that the product owner has just discovered a new, crucial requirement that forces us to rework our implementation.

Finish the task as specified originally and queue the revised version for the next sprint. The whole point of an agile approach is to lessen the impact of such a change by creating small iterations. You don't say how long your sprints are. If they are over 2 weeks then I would suggest to shorten them for this particular client until the quality of specs improves. This reduces time wasted without requiring cooperation of any external factors.

Other times, developers discover that recently deployed changes had first and second order effects on the business that were unanticipated (and unwanted) by the product owner and stakeholders that requested them.

This is more of a problem as it suggests that you have no one with a good understanding of the system. This should really be caught during the refinement stage of the tasks. If neither the customer nor the PO have the insight to watch out for these problems then you should involve the developers (or at least one developer with the necessary insight, like a "lead architect") in the refinement process. Dedicating more of the team's time to backlog grooming might help if your practices are good in principle but you lack the time to prepare enough tasks and then fill the remainder of your sprint backlog with unripe tasks.

Automated Testing might catch a few of these things as well (If you already test for A and B, then when you add requirement C you should get conflicts if implementing C throws off A and B)

Requiring more extensive acceptance criteria for a task might also help to provoke thought about the tasks consequences.

Answer 6

Try talking to your product owner. Tell him that the requirements are not clear to proceed with the design.

If the Product owner is able to solve it, proceed to the design meeting and so on.

Otherwise escalate your situation to the scrum master in the stand-up meeting so that your team gets to know the situation.

Waiting for the Retrospective meeting to raise this issue will be a waste of money and resources.

You wouldn't want to be the reason for the reduction in sprint velocity.