The Product Owner plays a particularly important role in DevSecOps and release coordination. In this final blog post on DevSecOps and release coordination, we will explore the Product Owner persona.
So far we have met the Release Coordinator, Security Architect, and the Operations Coordinator. Together with these other three key members of the release team, the Product Owner is responsible for ensuring the product has been built to the requirements. This typically includes what I term “full-spectrum testing” – unit, functional, regression, security, integration, user acceptance, and performance test.
In my previous post on DevSecOps and Release Coordination, I defined the concept of “presumptive release.” The idea is that all candidate releases are targeted for eventual deployment into production. This makes sense given that business value is derived from a development effort once it is delivered into the hands of the end-users. To that end, the Product Owner works closely with the other release team members to minimize the amount of overhead and approvals required to deliver value. This is the primary purpose of the release team – to ensure products are deployed to production safely, efficiently, and securely.
And so, last but not least, please meet Katie our Product Owner!
Introduction: Product Owner
As the Product Owner, I have responsibility and authority over my product, and my primary role is to understand and communicate application functional behavior based on defined business needs.
I am responsible for reviewing and prioritizing business requests as they relate to my product. I coordinate regularly with the business stakeholders to update product strategy and positioning in support of overall business goals. During development, I work closely with the Development Lead to size and assign work to specific sprints according to available resources, target release dates, and team delivery capacity. For the release process, I am responsible for assuring that the product readiness is complete for release into production.
As discussed previously, there are four required key system release readiness states. These four product statuses provide confidence to the release team that the software candidate has met all defined standards for production release. The release team consists of the Product Owner, Operations Coordinator, Security Architect, and the Release Coordinator. This team represents the sole deciders for what is, and is not, releasing to production. As illustrated below, the Product Owner is ultimately responsible for ensuring that a product has been properly evaluated, tested, and is ready for production. It should be noted, however, that most of the evaluation will be conducted by other teams, such as the development team conducting code and unit test and the business owner performing user acceptance. The Product Owner is expected to be involved in all product readiness assurance activities.
Figure 2. Example Release Readiness States
During the Release Coordination Meeting, the Product Owner reviews all of the testing and verification results with the release team, discuss any out-standing system issues, and asserts that the product is ready for delivery.
Tool Use and Workflow Responsibilities
The Product Owner may use many tools in the execution of her duties. Some of the possible tools are shown below (e.g. Jira/Confluence for requirements and collaboration). The workflow responsibilities are also shown and include backlog management, prioritization grooming, agile sprint planning, and development support.
Figure 3. Product Owner Backlog Responsibilities and Tool Use
Figure4. DevSecOps Product Owner Sprint Planning and Execution
Key Artifacts
There are several key artifacts that the Product Owner either uses, tracks, or otherwise manages:
- User Stories – A full description of a particular application functional behavior. Define (basic name and description) and detail (data elements, common behavior, exception handling, interface design) to a sufficient degree for estimation, development, and testing.
- Business Requests – These requests are collected separately from user stories and evaluated by the Product Owner against the product vision, budget, and delivery schedule.
- Product Strategy/Vision – This is an overall description of a particular software product, such as a web-site or collection of APIs. The product strategy outlines the purpose of the product/application, target audience, the value provided to the organization, the near and mid-term vision for product enhancement, and a detailed description of the functional behavior.
- Prioritized Work Item Backlog – This is a collection of work items (i.e. tasks, or user stories) that are prioritized in a single work backlog. The Development Lead and the Product Owner work together to groom the backlog items into sprint planning.
- Sprint Planning – Sprint planning is the core element of agile development. A sprint content is typically developed at least one sprint ahead of current work. The intent is to ensure that the team is assigned prioritized work based on the expected level of effort, team capability, resource count, and sprint length (e.g. 2 weeks).
Conclusion
It should be clear at this point that release coordination is an essential aspect of software development. Without some way to govern the release process, it is all be inevitable that increasing system integration will result in issues. However, there is also the need to ensure agile release practices to permit rapid development and delivery of business value. In these blog posts, I have presented one such approach to balance these two opposing forces – governance and agility. The use of various DevSecOps personas illustrates not only the role/responsibility of the team members but also how and when they interact. I hope these posts will help you with your DevSecOps journey!
