The PO has to make the hard decision about what to work on and when. He/She must understand the product deeply and be able to make the hard decisions. Also the PO should be able to test the system to accept the changes.
Furthermore. You don't really need to have endless lists of requirements. The most important thing to know is what is the next thing that you have to work on.
This actually has a nugget of wisdom. I wish I was more open to soaking up wisdom - and less likely to argue a point - when I was a junior dev. Or still now, really.
Moreover, if your PO can't define the goals, and what needs to be tested to get there, well you have a problem. Assuming the team is committed to some form of Agile and you have such a thing as a PO.
However, I also disagree with the main thrust of this comment. A PO should have responsibility, sure. But if that gets translated into an environment where junior devs on the team are expected to not know requirements, or be able to track them, then you no longer have a team. You have a group with overseers or minions.
There's a gray area between responsibility and democracy. Good luck navigating.
> Moreover, if your PO can't define the goals, and what needs to be tested to get there, well you have a problem.
In some work environments, there may be unspoken requirements, or requirements that the people who want the work done don't know they have.
For example, in an online shopping business the head of marketing wants to be able to allocate a free gift to every customer's first order. That's a nice simple business requirement, clearly expressed and straight from the user's mouth.
But there are a bunch of other requirements:
* If the gift item is out of stock, it should not appear as a missing item on the shipping manifest
* If every other item is out of stock, we should not send a shipment with only the gift.
* If we miss the gift from their first order, we should include it in their second order.
* The weight of an order should not include the gift when calculating the shipping charge for the customer, but should include it when printing the shipping label.
* If the first order the customer places is for a backordered item, and the second order they place will arrive before their 'first' order, the gift should be removed from the 'first' order and added to the 'second' order, unless the development cost of that feature is greater than $3000 in which case never mind.
* The customer should not be charged for the gift.
* If the gift item is also available for paid purchase, orders with a mix of gift and paid items should behave sensibly with regard to all the features above.
* Everything above should hold true even if the gift scheme is ended between the customer checking out and their order being dispatched.
* The system should be secure, not allowing hackers to get multiple free gifts, or to get arbitrary items for free.
* The software involved in this should not add more than, say, half a second to the checkout process. Ideally a lot less than that.
Who is responsible for turning the head of marketing's broad requirement into that list of many more, much narrower requirements?
Depending on the organisation it could be a business analyst, a product owner, a project manager, an engineer as part of planning the work, an engineer as part of the implementation, or just YOLO into production and wait for the unspoken requirements to appear as bug reports.
> there may be unspoken requirements, or requirements that the people who want the work done don't know they have
That is just restating the problem that the "PO can't define the goals."
It's a bigger problem in the industry. Somehow, the Agile marketing campaign succeeded, and now everyone is Agile, regardless of whether the team is following one of the myriad paradigms.
I can rattle off dozens of orgs doing Scrum, but maybe 1 or 2 that actually are. Maybe doing two weeks of work and calling it a sprint, then doing another two weeks of work...and so on. No defined roles. It's just a badge word on the company's culture page.
The companies that are really doing something Agile are the consultancies that are selling an Agile process.
That would be nice, and maybe I should have clarified why I asked the question. I was asked to add a new large feature, and some bugs popped up along the way. I thought better testing could have helped, and then I thought it would possibly help to list the requirements as well so I can determine which tests to write/perform. And really I thought I could have been writing those myself - PO tells me what is needed generally, I try to determine what's important from there.
Or maybe I just need to do better testing myself? There's no code reviews around here, or much of an emphasis on writing issues, or any emphasis on testing that I've noticed. So it's kind of tough figuring out what I can do
One I haven't seen mentioned yet - When Product is accountable & responsible for testing the outputs, they will understand the effort required and can therefore prioritize investment in testable systems and associated test automation.
When those aspects are punted over to architects/developers/QA, you'll end up in a constant battle between technical testing investments and new features.
The PO has to make the hard decision about what to work on and when. He/She must understand the product deeply and be able to make the hard decisions. Also the PO should be able to test the system to accept the changes.
Furthermore. You don't really need to have endless lists of requirements. The most important thing to know is what is the next thing that you have to work on.