3 ms·

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, r

by uticus 5y ago

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.

michaelt 5y ago
> 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.
- ibejoeb 5y ago
  > 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.
- creakingstairs 5y ago
  > an engineer as part of the implementation, or just YOLO into production and wait for the unspoken requirements to appear as bug reports. In my experience, engineer does it as part of implementation until they burn out and just YOLOs and leaves them for bug reports :p But to be more serious, I don’t think this is POs or one persons job. This is exactly why engineers should learn about their domain.

by uticus 5y ago

michaelt 5y ago

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

ibejoeb 5y ago
> 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.
creakingstairs 5y ago
> an engineer as part of the implementation, or just YOLO into production and wait for the unspoken requirements to appear as bug reports. In my experience, engineer does it as part of implementation until they burn out and just YOLOs and leaves them for bug reports :p But to be more serious, I don’t think this is POs or one persons job. This is exactly why engineers should learn about their domain.