The Product Owner represents the product's stakeholders and the voice of the customer; and is accountable for ensuring that the team delivers value to the business. This page describes the various pieces of how Agile Codex develops software, from the point of view of a product owner, rather than of a developer. We’ll define roles more precisely, and continue with project structure and practices, from the overall view down to the day-to-day.
There are two big risks in software development. The first, and most obvious, is not getting the thing done. The second is building the wrong thing. The project management tree swing cartoon below is famous amongst those of us who have engaged in any kind of software project management.
One way to avoid the second problem is to postpone doing anything until you’re sure you know what’s desired. But that really courts the first risk: not delivering anything.
At Agile Codex, we take a different approach that can be summed up in three simple rules:
With two roles—product owner and developer, we’ll explain some of the more specific roles that a product owner might fill.
The Product Owner writes customer-centric items (typically user stories), prioritizes them based on importance and dependencies, and adds them to the Product Backlog. Product owners are members of the customer organization who will be involved in specifying and accepting the software; in other words, those who are most interested in using the system to accomplish business or organizational goals. Scrum Teams should have one Product Owner. This role should not be combined with that of the Scrum Master.
Product owners are those who participate in any of these activities:
The project manager is an Agile Codex employee who is responsible for ensuring that the project continues to move forward toward the goal. The Master schedules most of the necessary meetings, ensures the Scrum framework is followed and prepares any documents.
The core responsibilities of a Scrum Master includes:
The development team, consisting of developers, architects, and designers, work together as one self-organizing, cross-functional team.
Members of the development team employ the following practices:
Quality assurance is a role that team members assume as needed to verify that a completed story meets its objective acceptance criteria before showcasing that story to product owners.
Most of our testing is fully automated, in the form of executable unit tests or integration tests. But automated tests can’t catch every possible error. The QA role should perform more “exploratory” testing, manually exercising the feature and looking for problems. When possible, the developer in the QA role should identify additional automated tests that would be helpful and either write such or write a new story card for more involved tests, so that they can be prioritized and scheduled by the customer. If one developer can perform the QA role for the story which was done different developer.
