Product Owners - level of involvement with .feature files
I am involved in a project where Given-When-Then formatted stories are written by the Product Owner (in a web-based story repository / JIRA), then created by Developers, while system test automation (written as SpecFlow .feature files) is built by the Tester to cover all testable behaviours. What seems to happen as a natural part of the lifecycle is that the test automation logic will combine, extend and clarify the details of the original acceptance criteria. This further definition can be lost, however, since the .feature files are only reviewed by the Tester, while the Product Owner wants only to be exposed to the original set of stories and acceptance criteria. It seems like we might be breaking BDD by not exposing the .feature files to the Product Owner, but even if the latest .feature files are available through a version control tool, does that mean our Product Owner would need to learn about that as well? And even if they access these files through version control, how are Product Owners supposed to write useful GWT statements without also using the IDE to discover/intellisense the existing step definitions? What experiences are others having with this type of situation? Any suggestions are appreciated. Thanks.
A lot of your question talks about the tools, Jira, source control, etc. I think you are letting the process that the tools facilitate is guiding your thinking too much. If you read Liz Keogh, she repeatedly talks about the conversation that you need to have in order to fully define and form your ideas about the feature that you are developing. I think your current process is isolating people too much and preventing the conversation from happening. As you say, the POs are not reviewing the updated specifications, to me, that seems to be because they are being produced in isolation originally. Since the testers requirements aren't met then they update the specifications without the POs being involved either. If you could get all parties involved in a conversation initially then the process However if you decide to keep your current workflow, there are some features of Jira that might also help you to improve it. See if you can get FishEye added to your Jira installation. This enables you to produce code reviews, which would be a simple means of highlighting the specification changes to your POs and kicking off a conversation about those changes. You could find that some changes only need a few comments electronically, others might require picking up the phone or talking it over face to face, but at least they aren't missed. Just looking at the highlighted changes would certainly be better than opening up the whole source tree to the POs and possibly missing some of those specification changes inside all the other source files.