There’s at least one company out there which have the best technical analyst.
Product owners (PO) don’t need to spend hours on defining business logic. Anyway they get just requests from stack holders (SH), and can not extract important assumptions they make. Also they are not aware of many constraints those rules need to obey. Here is how they work.
There’s need to handle renewal feature in a new way, PO asks how much “complete rewrite” would take. After The Analyst realizes this is as much requirements as he gets for now he gives estimate 1 to 6 months +/-50%. That was #iteration 1.
Our PO is not a jerk – he asks because stakeholder asks. With this estimate he’s happy – stakeholders will understand now that to estimate a cost of the road one need at least length of that road… for a start.
PO comes back and says: we need to get back to the topic, but I don’t have specs. The Analyst says: no problem man, try to give us at least one example of client response with renew products and promos he want’s us to handle.
He comes again with an example and one screenshot with some changes (this communicates client side needs). The Analyst simultaneously takes a look from distance and examines it on microscopic levels. Bumps it against current system constraints and extracts hidden assumptions. Then asks PO if those assumptions are right (and suggests that it would be really great – it would make dev team job easier and outcome would be better – how can he tell by the way?). You can call this #iteration 2.
The Analyst can even make experiments, researches and proofs of concepts (iterations 3, 4 and so on). He can even implement features because The Analyst is a whole Backend Team.
I hope you liked my little story, now I’ll try to summarize why it’s a good setup.
You don’t want your business people to devise business rules by themselves. They don’t have enough knowledge about the constraints, and most probably lack tools.
One of the best tools you’re almost guaranteed to find in dev team is: ability to generalize. We do it every day. Every. Freaking. Day. Even when we’re not at work.
Don’t ask your business people to define rules – ask them to provide examples. The more the better. And give them to your developers/programmers. They will find rules. And exceptions to the rules. Edge cases, inconsistencies. They will tell you when something makes no sense, when something is not possible and when more examples are needed. They will also provide few solutions for you to choose.
You want organized idea kicking between business and devs.
Another benefit of that is whatever is in such analyst mind is already in Whole Dev Team Mind(tm). No further explanation needed.
Even if you like this idea – it is not possible to have it in a finger snap. But since this story is actually based on true events – I’ll try to extract factors which lead for possibility of such setup.