How can we maintain stakeholder involvement in Scrum Projects? One of the Benefits of adopting any Agile Framework is the acknowledgement that Stakeholders are an integral part of Product Development. If Customers are involved throughout the Product development process, their Confidence level will rise. They will also be able to intervene where the Product is diverging from their original Vision. The need to Change Requirements once Development has started is also recognised and expected in Agile Development. There is no blame or recrimination attached.

Product Development is complicated and incorporates lots of unpredictabilities. There are many unknowns when the Project starts. These unknowns will need resolving along the way as Product understanding grows. The part that Stakeholders play in a typical Scrum Development is clearly defined. From Concept through to Product completion their participation is non-negotiable if a successful Product is to be delivered.

Key Stakeholder Involvement in the Product Journey

Stakeholder Management in Scrum is simple; Stakeholders are defined as Sponsors, Customers and/or Users. The Scrum Framework does not differentiate between Stakeholders. This is just like there is no distinction of members of the Scrum Development Team. There are however distinct Roles and activities fulfilled by Stakeholders before and during the Scrum.

Stakeholder Involvement: Concept, Design, and the Product Vision

The initial Concept and design of the Product is done by the Stakeholders. The ideal Stakeholders for this Role use design thinking and Lean Startup techniques to specify what the Product must be. This culminates in the Project Vision and the description of the Minimum Viable Product (MVP). The MVP is a stripped-down and functional Product without Bells and Whistles. The Leaner the Product, the quicker the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum development Team) will be able to deliver to requirements.

Pre-Project: choosing the Scrum Team

As soon as the MVP design has been finalised, a Project to Develop it can be begun. The Stakeholders kick this off with the selection of the Product Owner. This person has a critical Role throughout the Project: They are:

• the proxy Stakeholder within the Project (the Voice of the Customer, or VOC).
• the steward of the Product Requirements and specifications.
• accountable for defining who the Stakeholders are for Project success.
• the Team member who is accountable for external (i.e. Stakeholder) interactions.
• the individual who can stop or cancel a Project, where needed.

Add to this the Responsibility for delivery of a successful Product. It is clear that this is not a Role one takes on lightly. The Product Owner, when selected, plays a part in choosing the Agile Scrum Master. The Scrum Master assists in picking the Development Team.

Stakeholder Involvement: Stakeholders as Storytellers.

The ability of a Stakeholder to explain clearly and concisely what is needed must not be Under-Estimated. There are circumstances where the Scrum Product Owner plays a significant Role. They act as a proxy for the Stakeholders. However it is suggested to engage as many of the Stakeholders as possible in composing User Stories prior to the Sprint Planning Meeting. This gives them a vested interest in the Project.

During the Project: Stakeholders as Change Agents.

Stakeholders are encouraged to monitor development, both as part of the Scrum processes and on an ad-hoc basis. The Scrum Team keeps a Burn-down chart, which maps progress and is readily available for assessment at any time. Towards completion of each Sprint (Iteration), a Sprint Review Meeting is held. This is a “Show-and-Tell” for the Benefit of Stakeholders. During this meeting the Scrum Development Team describes, and, if possible, shows what was accomplished during the Sprint.

This is an Opportunity for the Stakeholders to request Changes prior to the start of the next Sprint. Changes however can be requested at any time. The Changes will be noted and then assessed for criticality and priority for inclusion (or not) in the Product Backlog. No Changes are introduced throughout the Sprint in progress. The Changes required by Stakeholders typically arise as a result of the uncertainty of what the Product will resemble at the start of the Project.

We found these books great for finding out more information on Agile Scrum:

Project Completion: Accepting the Release.

There might be one or several Releases throughout the Project. On each Release, Stakeholders accept the Release if they are satisfied with what has actually been provided. The Product Owner is instrumental in determining whether each component meets its Acceptance Criteria during the Sprint

Project Completion: Looking Backwards.

At the end of each Project, a Project Retrospective needs to be held. This is where the Scrum Team and Stakeholders Review how the Project was conducted. They discuss the successes that were attained and any drawbacks that could be prevented in future. There are also Sprint Reviews.

Getting the Desired Stakeholder Commitment.

From the interactions listed above, it is clear that Stakeholders play a major part in the joint Effort to Develop the successful Product using Scrum. In order to ensure the required level of commitment, there are 2 important success aspects:-.

• A dedicated and committed Product Owner.
• Stakeholder who comprehend their Role and commit to it.

We found these books great for finding out more information on Agile Scrum:

In Companies that are experienced in Agile Development, Stakeholders know their Role and what their Responsibilities are. Companies that are new to Agile and/or Scrum and are used to Traditional Projects with minimal Stakeholder participation might not understand the additional commitment that is needed for a successful Scrum. The Product Owner may find that some additional coaching and Meetings are needed with Stakeholders in such Organisations, up until the message is absorbed and the new method of Working is embraced.