Navigating the Stakeholder Landscape in Agile Sprints: A Product Manager’s Perspective

Stakeholder Management in the Sprint Process:

Product Manager: The product manager defines the product vision, analyzes and prioritizes requirements during sprints. Additionally, they gather feedback from stakeholders and update the product roadmap.

Tech Lead: The technical lead makes technical decisions throughout the sprint, manages the development process, and provides technical guidance to team members.

Developers: Developers code user stories during the sprint and create software that meets the requirements.

QA Testers: Quality assurance testers create and execute test scenarios to ensure software quality, report bugs, and provide feedback to the development team.

UI/UX Designer: User interface and user experience designers create interface designs during the sprint and manage usability testing.

Business Owner: Business owners ensure that the product aligns with business strategy and requirements, and represent the needs of stakeholders.

Stakeholder: Stakeholders are involved in the product development process, provide feedback, and validate the requirements of the final product.

Agile methodologies, while accelerating software development processes, necessitate the integration of various stakeholders into the process. As a product manager, understanding and managing the roles and responsibilities of different stakeholders in sprints is critical for successful product delivery

Ideal Scenario in Sprint Planning:

Sprints are organized in 2-week periods.

Official holidays, planned leaves of the team, or company-provided leave days are agreed upon with stakeholders in the quarterly planning phase to determine the team’s capacity in man/days for the sprint.

Product Owner & Tech Lead should determine the sprint goal (Task/feature) before the sprint starts. Together, they discuss the tasks and priorities required to achieve this goal.

Tasks brought into the sprint cannot be included or given priority in case the necessary documents and expectations from stakeholders (Design/Other dev./Business decision, etc.) are not met.

PO should communicate the items brought into the sprint to stakeholders at the beginning of the sprint and should finalize the task’s requirements and agreements before the sprint if there are dependent teams or individuals.

At the end of the sprint, PO & Tech Lead conduct a Retrospective to review the quality of completed tasks and assess their compliance with acceptance criteria. Feedback is gathered, and lessons learned are reviewed for future sprints; action items are attempted to be implemented in the next sprint.

Each task is agreed upon with the participation of all developers using Planning Poker cards during planning. In the event of scope changes or addition of Change items, the Planning Poker Points may change. Workload to be taken into the sprint is determined based on the team’s velocity. Reports on the team’s average workload and potential range are shared with the team at the end of the sprint.

In general, while the sprint each team runs may vary, I wanted to share a sample framework with you for illustrative purposes.