One of the Benefits of embracing any Agile Framework is the acknowledgement that the Stakeholder is an integral part of Product Development. If Customers are included throughout the journey towards an ended up Product, their Confidence level will increase as the Project advances. Likewise the will be able to intervene where the Product is diverging from their original Vision.

The Ability to Change Scope once Development has actually started is also recognised and Expected in Agile Development. There is no blame or recrimination connected. This is because it is Understood by all included that Product Development is Complex and integrates many unpredictabilities and unknowns when the Project begins. These will require resolution along the Way as Product understanding grows. The part that Stakeholders play in a Scrum Development Team is Clearly defined, from Concept through to finished Product. Their participation is non-negotiable if an effective Product is to be delivered.

Key Stakeholder Interactions in the Product Journey

Stakeholder Management in Scrum is simple; Stakeholders are defined as Sponsors, Customers and/or Users. The Scrum Framework does not distinguish between types of Stakeholders. Just like there is no differentiation of members of the Scrum Development Team. However, there are stand out Roles and activities filled by Stakeholders prior to and during the Scrum.

Pre-Project: Concept and Design, the Product Vision and the Stakeholder

The initial Concept and design of the Product is Work carried out by Stakeholders. The perfect Stakeholders for this Role use design thinking and Lean Startup techniques. They can specify what the Product must be. This culminates in a 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 will have the ability to deliver to specification.

Pre-Project: Picking the Scrum Team

Once the MVP design has actually 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: he or she is

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

Add to this the Responsibility for shipment of an effective Product, and it is clear that this is not a Role one handles lightly. The Product Owner, when selected, plays a part in picking the Project Scrum Master. The Scrum Master helps the Product Owner in picking the Development Team.

During the Project: Stakeholders as Storytellers.

The capability of a Stakeholder to explain clearly and concisely what is required should not be Under-Estimated. There are situations where the Product Owner plays a significant Role. In some cases acting as a proxy for the actual Stakeholders. However it is a good idea to engage with as Many Stakeholders as possible in composing User Stories. This gives the Stakeholders a vested interest in the Project.

During the Project: Stakeholders as Change Agents.

Stakeholders are motivated to track progress, both as part of the Scrum processes and on an ad-hoc basis. The Scrum keeps a Burn-down chart, which maps progress and is offered for assessment by the Stakeholders at any time.

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

Towards the end of each Sprint (Iteration), a Sprint Review Meeting is held. This meeting is a “Show-and-Tell” for the Benefit of the Stakeholders. Within the meeting the Team describes, and, if possible, shows what was Developed during the Sprint. This is an Opportunity for the Stakeholders to request Changes prior to the start of the next Sprint.

Changes can be raised at any time. The Changes will be kept in mind and assessed for criticality and priority. They may then be included (or not) in the Product Backlog. No Changes are introduced during the Sprint in progress. The Changes needed by Stakeholders usually arise as an outcome of the Uncertainty of what the Product will be like at the start of the Project.

Project Completion: Accepting the Release.

There may be one or numerous Releases during a Project. On each Release, Stakeholders accept the Release if they are pleased with what has been provided. The Product Owner is important in identifying whether each element fulfills its Acceptance Criteria during the Sprint.

Project Completion: Looking Backwards.

At the end of each Project, a Project Retrospective ought to be held. Within this meeting the Team and Stakeholders Review how the Project was conducted. Successes that were accomplished and any shortcomings that could be avoided in future are noted. Sprint Reviews generally only involve the Scrum Team. However there must never be a veto on Stakeholders going to any Scrum Meeting, although it may just remain in an observer capability.

Getting the Desired Stakeholder Commitment.

From the interactions listed above, it is clear that Stakeholders play a significant part in the Development of the Product. In order to ensure the Required level of commitment, there are two important success factors:-.

• A Dedicated and Committed Product Owner.
• Stakeholder who understand their Role and Commit to it.
  The Product Owner is the VOC, and as such, is the representative of all the Stakeholders for the Team. He has to comprehend this and shelve his “typical” Role for the period of the Project. The Product Owner must likewise be a frequent and proactive communicator to Stakeholders, as he is the external voice of the Project. He should likewise guarantee that Stakeholders are active individuals in the Project; after all, if the Project stops working, he has a heavy Responsibility.

The Stakeholders need to understand and accept the commitment needed from them, from inception to conclusion. The participation described above is the minimum Requirement. Every Stakeholder is welcome to become more Involved, if he feels it will include Value.

In Companies that are experienced in Agile Development, Stakeholders understand their Role and what their Responsibilities are. Companies that are new to Scrum and are Familiar to Traditional Projects with minimal Stakeholder involvement might not understand the additional commitment that is needed for a successful Scrum. The Product Owner might discover that some extra coaching and Meetings are required with Stakeholders in such Organisations, up until the message is taken in and the brand-new method of Working is embraced.