Agility is an iterative approach to digital product development in which you start by achieving a Minimum Viable Product and then improve it incrementally.

Today, the Scrum methodology is the most widely used agile method in business (two-thirds of agile practitioners) and is based on a product team working together to move forward. Thus, during each cycle, the team plans, designs, tests, develops and approves new functionalities that are ready to go online at the end of each sprint.

Schematization of the Scrum methodology

Source : Hubvisory

What roles are hidden behind a Product Team?

The Scrum Guide defines a Scrum team as a self-organized, multidisciplinary team, made up of 3 main roles at the same hierarchical level:

• the Product Owner
• the Scrum Master
• and the production team

The 3 main roles of a Product Team under Scrum methodology

Source : Hubvisory

The Product Owner

The Product Owner - aka PO - is the guarantor of the product. It’s the person who collects user needs, translates them and carries out the final product vision.

Thus, the Product Owner is very attuned to the end users, must understand their needs and then translate them into functionalities by creating User Stories.

Once the needs are clarified - and if they’re lucky enough to have a UX/UI team available - the Product Owner may work with a Product Designer who will take care of the user journey production and layout.

With models in hand, the Product Owner can finally start writing User Stories and present them to their developer team during grooming. This refinement meeting allows the Product Owner to make the technical team aware of the user's needs, to discuss future functionalities in an exhaustive way and to anticipate potential technical alerts.

Following these exchanges, they may have to cut out User Stories that are too heavy to be processed in a single iteration and finish preparing them for the next sprints.

The ecosystem around the Product Owner

Source : Hubvisory

Within the product team, the Product Owner is therefore responsible for carrying out the vision of the product and framing it via a roadmap. On a daily basis, the Product Owner feeds the backlog with User Stories which must then be prioritized. Prioritization is essential work that allows the Product Owner to know what to commit to in the upcoming sprints and to optimize their technical team’s time by delivering maximum value to the end user following each sprint.

In addition to regular communication with the previously stated players, the Product Owner also works with acceptance teams - also called QA, short for Quality Analyst or testers. Since they create the test cases via acceptance criteria, they’re frequently in contact with testers in order to guarantee the delivery of a quality product version.

The Product Team expects flawless organization from the Product Owner to plan both ongoing and future developments. As such, communication and transparency are also key qualities teams expect from a successful Product Owner.

The Product Owner therefore has a particularly important role, since they are the central hub of the team that all other product stakeholders revolve around.

Though the Product Owner provides direction to the team on product changes, they have no hierarchical power over the Scrum Master or production team.

The Scrum Master

The Scrum Master's role is to ensure the application and respect of Scrum values ​​and practices while ensuring that obstacles to the team's productivity are removed.

The different roles of the Scrum Master

Source : Hubvisory

Their mission is to help the team work in the best possible conditions. They must therefore protect it from all disturbances that may come from the outside but also facilitate internal communication and dialogue with the Product Owner.

They are also the ones who ensure that various agile ceremonies (daily meeting, grooming, sprint planning, retrospective, etc.) take place and that all the members of the team understand those ceremonies. We therefore see the role of Scrum Master as a facilitator within a product team.

The production team

The production team is a multidisciplinary team that works incrementally to deliver a part of the final usable and testable product at the end of each sprint or iteration.

It is ideally composed of 3 to 8 people bringing together:

• mainly developers responsible for the technical production of User Stories and the technical arbitrations to be made,
• a Product Designer who employs user research in the design of the product.
• a Quality Analyst (receiver / tester) whose role is to test each ticket and validate its functionality.

Developers within the production team

The developers will create tasks to prepare the development of the User Story (US) in advance. This analysis phase allows them to quantify / score the US via techniques such as poker planning, t-shirt sizes, etc., and to help the team project the project pace and workload.

Once the tickets are embedded in the sprint, the technical team organizes the distribution of tasks according to the technical skills of each (front / back / Fullstack Developer).

Each member of the development team thus takes charge of several tasks while guaranteeing the proper implementation and the quality of what they deliver. Once the management rules have been developed, the technical team reviews the acceptance criteria in order to verify the functional expectation. It then carries out extensive unit tests to deliver quality code with the least possible technical requirements.

Once the User Story has been developed, it then passes into the hands of the Quality Analyst who will ensure the functional compliance of the tickets according to different test cases. If anomalies are detected, the developers are responsible for analyzing them and making the necessary corrections and / or additions.

Finally, on top of User Story technical development, they must also document their code so that new developers can get up to speed quickly, and also produce technical documentation. This step is essential to ensure the maintainability of the product and limit risks in the event of turnover.

The Product Designer within the production team

The Product Designer is very close to the end users. The Product Designer meets them, conducts user research and makes the journey as ergonomic as possible. They’re proximity to users allows them to collect as much feedback as possible and continuously improve their proposals.

The Product Designer’s double UX/UI hat allows them both to respond to the ergonomic issues of the product by paving a clear path, and interface issues and by implementing graphic elements that help guide the user on the product.

The Product Designer therefore exchanges regularly with the Product Owner once the need has been clarified, but it is not uncommon for certain developers, in particular front-end developers, to turn to the Product Designer to jointly validate the expected behavior of certain graphic components.

The recipe team within the production team

The testers are the last links in the chain before a product version can be delivered in a production sprint. They’re the ones who test all the functionalities and validate or invalidate them. The testers carry out cases via the acceptance criteria written by the Product Owner and can sometimes discuss with the latter if they have doubts about which tests to perform.

If a product does not comply with the specifications of the User Story during testing, the tester creates the anomaly to a responsible developer. This allows the developer to check their code and make any necessary corrections.

Once all the sprint tickets have been reviewed, the testers launch non-regression tests - or TNR - in order to verify that the current product increment has not generated any side effects that could degrade the product compared to the previous version. These TNRs are often automated in order to limit the processing time of each version.

The validation of the tests is sometimes documented by the submission of an acceptance report, a document validating the delivery of the product and authorizing the technical team to push the product increment into production.

Once a product is delivered to production, the acceptance team can then check that everything is in order and inform the whole team.

If necessary, several round trips take place between the developers and the testers in order to quickly find the source of bugs. Once they’ve been identified, the developers can correct them, and the testers again ensure they comply before giving the go-ahead for delivery of a hotfix (overwritten / replaced system) in production.

It would be wrong to think that a Product Team only interacts between three disciplines: the Product Owner, the Scrum Master and the production team. Indeed, an agile team is in constant contact with other stakeholders essential to the success of a product.

The other roles that revolve around a Scrum Product Team

Product Owner, Scrum Master and the production team obviously interact with other trades essential to the proper development of the product. Here is a non-exhaustive overview.

The Agile / Product Coach

The role of Agile / Product Coach is not guaranteed in all Product Teams or even in general in a product organization, but it is not uncommon for teams to work with one of them.

The role of the Coach is not to wade into production but to bring their expertise on agile and product methodologies. They can help with methodologies used both at a team level and for the organization/processes. They can also be in contact with both the business and management.

They accompany all the team stakeholders: the Product Owner, the Scrum Master and the production team; leading them to make the best decisions concerning the organization. Listening is an Agile Coach’s strong point and their positive philosophy allows the team to evolve in a virtuous atmosphere maximizing productivity.

The Business Analyst

Much like a Coach, Business Analyst is not a guaranteed role in all organizations. But when there is one, they are the number 1 ally of the Product Owner. Indeed, the latter regularly contacts the Business Analyst to request data, KPIs and quantitative / qualitative studies that help with decisions on the development of the product. They can also have an expert look at certain parts of the business process and provide valuable information to the Product Owner.

The Business Developper

Sales people know users best since they are constantly in contact with them. Indeed, they’re the ones who sell the product, so they’re usually very familiar with it.

Being close to users, they are often on the front line to collect user feedback and help initiate numerous requests for changes from the Product Owner.

Armed with that feedback, the Product Owner must be able to assess the value of each request and argue factually with the sales department when an idea for development is not a backlog priority.

Beware, however, of sales-driven organizations that sell non-existent features. In such a case, the relationship can be complicated and lead to conflicts over the product vision.

Other technical roles

The team may also be required to interact with other technical roles in the organization, for example an architect, who without working on the product on a day-to-day basis, will be responsible for ensuring the consistency of the team's technical choices with the IS strategy.

Thus, the three roles provided for by Scrum are enriched by exchanges with the other trades of the company to build an ever better product. Agile approaches focus on individuals and interactions, so a good product team will be able to rely on everyone's skills to feed their vision!