The Optimization Model case, Optimize System Value, was not included in the survey because of a lack of space in the questionnaire but a person that would score 15+ on Optimize System Value is someone who cares deeply about developing a system that accurately delivers requested business value and in so are often recruited for testing efforts. Because of this, you might think they would also score 15+ on Optimize System Quality but this is not necessarily true. One who scores 15+ on Optimize System Value, traditionally an analyst, is motivated to deliver a system that does what it is supposed to do while one who scores 15+ on Optimize System Quality, traditionally a tester, is not only motivated to deliver a system that does what it is supposed to do but they are also motivated (and sometimes more so) to deliver a system that doesn’t do what it’s not supposed to do. Is it possible therefore to have a well-functioning team without someone who scores 15+ in Optimize System Value? No, I think not. This strength may belong to a Product Owner, a tester, a developer, or even a ScrumMaster but it has to be present on the team if the Product Backlog has any hope of being a reliable input to product development. Someone who scores 15+ on Optimize System Value helps the Product Owner accurately represent requested business value in the Product Backlog and makes sure the user stories gathered are independent, negotiable, valuable, estimatable, small and testable – not a simple task. They also work with the Product Owner to create Acceptance Tests that determine the criteria that makes a developed user story acceptable. In other words, they are driven to do whatever it takes to make sure the system accurately delivers requested behavior.
Someone who scores 15+ on Optimize System Quality may also work with the Product Owner to create Acceptance Tests but they will also create additional test assets to make sure the system performs within acceptable parameters and is secure, reliable, maintainable, operational, etc. My experience has been that delivery of requested behavior is what makes a user story “done” and that these types of tests are done outside the Sprint boundary. But they definitely could be included in the Acceptance Test suite. I guess it is a matter of what individual teams consider “done”. As anyone who scores 15+ on Optimize System Quality knows, a system that can be compromised and/or rendered unusable adds no value to a business.