3 ms·

What's always missing with any kind of feature work is context. User stories can kind of provide some context ("why"), but the best method I've found is to wri

What's always missing with any kind of feature work is context. User stories can kind of provide some context ("why"), but the best method I've found is to write expectations--it will do X, Y, and Z. Then have some kind of call to confirm understanding and provide context. A lot of companies skip or eliminate this last step because PMs are busy, developers are introverts, some other excuse. But the fact is, spec-only development very rarely achieves the desired outcome because the developer can't or isn't allowed/trusted to see the forest from the trees.

marcinzm 6y ago
I totally agree. Developers are intelligent people who know a lot more about how to best execute a ticket than the people writing tickets. They however know a lot less about the context than the people writing tickets. Converting developers into task executing machines seems like you lose a lot of the advantages of having intelligent people in the loop.
endiangroup 6y ago
AD: Agreed! I'd look into BDD as an exploration and specification process (it's not just a testing methodology!), it taps into the goals of your users and features that satisfy those goals. See my comment below for a crude example.
smoe 6y ago
I don’t really care what it is called and what format it comes with, but understanding the why of a task is crucial to me. There is a good chance that I over- or under-engineer otherwise. And understanding it I can often come up with simpler more maintainable results than if someone imposes the solution on me without talking about the problem. Also spec-only development is horribly boring in my opinion.
splistud 6y ago
So far all of the comments here are just dances around how we perform business analysis. It is a role, is it a process, will we split it into pieces in our workflow, will we do it along with a prototype?

marcinzm 6y ago

I totally agree. Developers are intelligent people who know a lot more about how to best execute a ticket than the people writing tickets. They however know a lot less about the context than the people writing tickets. Converting developers into task executing machines seems like you lose a lot of the advantages of having intelligent people in the loop.

endiangroup 6y ago

AD: Agreed! I'd look into BDD as an exploration and specification process (it's not just a testing methodology!), it taps into the goals of your users and features that satisfy those goals. See my comment below for a crude example.

smoe 6y ago

I don’t really care what it is called and what format it comes with, but understanding the why of a task is crucial to me. There is a good chance that I over- or under-engineer otherwise. And understanding it I can often come up with simpler more maintainable results than if someone imposes the solution on me without talking about the problem. Also spec-only development is horribly boring in my opinion.

splistud 6y ago

So far all of the comments here are just dances around how we perform business analysis. It is a role, is it a process, will we split it into pieces in our workflow, will we do it along with a prototype?