Stakeholder Engagement - Agile Wire frames and Project Charters

This ‘Stakeholder Engagement: Stakeholder Management and Principles’ tutorial, is part of the PMI-ACP Certification course offered by Simplilearn. In this tutorial we will talk about Stakeholder Principles, Agile Project Charters and Agile Wireframes.


After completing this lesson, you will be able to:

  • List the principles of stakeholder management
  • Develop an Agile Charter and Business Case
  • Describe wireframes, user stories, and Agile Personas
  • Explain product backlogs and story mapping
  • Assess the Agile community and stakeholder values

What is Stakeholder Management?

A stakeholder is anyone who has a “stake” in the project, a person whose interest is positively or negatively impacted by the project’s outcomes, or a person who can impact the project positively or negatively. The initial stages of a project are focused on identifying all the stakeholders. Internal stakeholders, listed in the image, are evident and easily identified.

However, significant effort is required to identify external stakeholders. The image lists some of them. Effective stakeholder management plan is one of the most important determinants of project success, and it can be achieved through effective and timely communications.

The Principles of Stakeholder Management

The ten principles of stakeholder management from R.E. Freeman’s ‘Managing for Stakeholders’ are:

  1. Stakeholder interests need to go together over time. We need intensive communication and dialogue with stakeholders--not just those who are friendly.
  2. We need a philosophy of volunteerism to engage stakeholders and manage relationships ourselves rather than leave it to government or organizational governance.
  3. Stakeholders consist of real people with names and faces and children. They are complex.
  4. We need to find solutions to issues that satisfy multiple stakeholders simultaneously.
  5. We need to generalize the marketing approach. Everything that we do serves stakeholders.
  6. We never trade off the interests of one versus the other continuously over time.
  7. We engage with both primary and the secondary stakeholders.
  8. We act with the purpose that fulfills our commitment to stakeholders.
  9. We act with an aspiration towards fulfilling our dreams and theirs.
  10. We constantly monitor and redesign processes to make them better serve our stakeholders.

Project Charter

Chartering is a process that authorizes the team to start working on the project. A Project Charter is a key reference document listing the stakeholders actively involved in the project. Although the purpose of the Charter is to provide an overview of the project in terms of goals, costs, budget, deadlines, deliverables, communication channel, and frequency and sponsor, it also provides a ready reckoner for the stakeholders who are interested in the project outcome. An Agile Charter is typically documented on a whiteboard. A chartering session helps a team:

  • understand the parameters of teamwork and its context within the project;
  • make well-informed decisions. This is important as Agile teams are self-organized.
  • identify the value the project will deliver to the business.
  • develops the trust and confidence needed in the project.

Agile Project Charter

The Project Charter aims to answer the W5H that is, What, Why, Who, When, Where, and How. The Charter provides insight into:

  1. What is the project about?
  2. Why build this product? Is it a business decision, mandated by law, or a team initiative?
  3. Who is the project community? This includes the team, customers, end users, and other stakeholders.
  4. What are the expected start and end date of the project?
  5. Where is the project being executed? This refers to the location: onshore, offshore, or delivery center.
  6. How will we know if it is successful? At the outset, the team has to define the success criteria for the project.

Agile Project Charter Components

The three components of the Agile Charter are the vision, mission, and success criteria.

The vision is a brief statement that articulates the desired “end state” for the project. It answers the ‘WHY’ and gives the project a higher purpose.

The mission of a project is a paragraph defining the project, which forms the ‘WHAT.’ It also includes the objective of the project.

The success criteria describe the factors required for a project to be successful.

Learn more about Project charters. Click for course preview!

Business Case

A business case is meant to justify a project or the features to be included in a product, from a business benefits perspective. A business case, usually part of the project charter, helps organizations select one profitable project from many. Business cases help in project selection as they:

  • Reflect the expected benefits
  • Communicate the anticipated costs of the project
  • Include high-level strengths, weaknesses, opportunities, threats or SWOT analysis
  • Identify key stakeholders
  • Identify the risk of not undertaking the project
  • Present the index to track inflation and its impact on anticipated benefits

Note that, while the Product Owner is typically accountable for creating and presenting a business case, inputs from the users, management, and other key stakeholders are also important.

Understanding Stakeholder Needs

Agile methods acknowledge the semantic gaps that always exist between the development team, which converts customer requirements into IT solutions, and the needs of the end customer. Therefore, many artifacts are used to address such gaps. It can be done by facilitating discussion, identifying the best possible solution, and ensuring constant collaboration.

The artifacts used to ensure knowledge sharing at the early stages are:

  • Wireframes
  • Personas
  • User stories
  • Models

These artifacts ensure the unimpeded flow of information and value throughout the project lifespan.

Agile Wireframes

Given below are features of wireframes. A wireframe:

  • is a low fidelity, non-graphical prototype or artifact
  • should be simple with no colors, graphics, or other layout features
  • shows the skeleton of a screen, representing its structure, and basic layout
  • contains and localizes contents, features, navigation tools, and interactions available to the user.

Agile wireframes are:

  • black and white, and are accompanied by some annotations to describe the behavior of the elements, their relationships, and their importance.
  • often put in context within a storyboard, and are frequently refined.
  • used as a communication tool that serves as an element of conversation and confirmation of ’Agile’ user stories.

Agile Wireframes - Real Life Example

User stories combined with wireframes are effective in capturing business requirements. The Simplilearn Solutions Private Limited website, initially designed as a Wireframe, was populated with videos and articles. The graphic shows the ‘Before’ and ‘After’ versions of the website.

User Story

Unlike the use cases or functional requirements documents used to gather requirements in the 1990s and early 2000s, a user story is a lightweight mechanism to quickly capture requirements. As the name suggests, it describes how a user will interact with the system to complete a particular task.

It is the lowest level of detail that the team will work on to address a requirement and acts as an agreement between customers and team members on the work that will be done in an iteration. A user story provides a medium to:

  • gather basic information about stories
  • record high-level requirements
  • develop work estimates
  • define acceptance test.

User Story - Card, Conversation, and Confirmation

The acronym, CCC, reflects the intent of user stories. CCC stands for Card, Conversation, and Confirmation.

The Card is where the story is documented, typically written by hand on an index card about 4 inches long and 6 inches wide. The idea behind using a card is to limit the size of each story; with the result that the description has to necessarily be clear and direct.

‘Conversation’ implies that the story must be the starting point of a conversation between the team and the Product Owner, who would typically write the story. The details involved in executing a user story are left to the team, giving them an opportunity to innovate in the course of implementation.

‘Confirmation’ represents the acceptance tests for the story. Acceptance tests are usually written on the back of the card and help the team identify if their work satisfies the requirement. Essentially, user stories provide a light-weight mechanism to document requirements and rely on people to collaborate on how to best implement the requirements. This is in line with the ‘people over process’ principle of the Agile Manifesto.

User Story-Attributes

The attributes a user story must possess to meet the goals of the Product Owner can be represented using the acronym INVEST.

“I” stands for Independent, that is, the stories must be independent of each other and deliverable as an individual unit.

“N” stands for Negotiable, that is, the story must be negotiable in terms of implementation.

“V” stands for Valuable, that is, the user story must create some value for the customer.

“E” stands for Estimable, that is, the story should be clear enough for the team to estimate the amount of work involved with reasonable accuracy.

“S” stands for Small, that is, it must be possible to complete the story within a single iteration. Scrum, for instance, demands that a story should not require more than 40 staff-hours.

“T” stands for testable, that is, the story should be testable for correctness based on the description and success criteria.

Story Card Information

The story card can also capture a variety of other details; the team chooses the information that will provide the most value. These details include:

  • Story identifier and name, which includes a short name and unique identifier
  • Story description, which includes a sentence or two that describe the features per customer’s point of view.
  • Story type, which includes categorizing a story as C or T, that is, is it a story requested by the customer or a technical story brought forward by the development team
  • Estimated work, which includes the estimated effort needed to deliver the story, time for requirement gathering, design, coding, testing, and documentation
  • Estimated Value Points, which includes the relative Value Points for the user story.
  • Requirements uncertainty, also called the “exploration factor”, categorizes the variability in requirements as: erratic, fluctuating, routine, and stable.
  • Story dependencies, which includes dependencies that could influence story implementation sequencing.
  • Acceptance tests, which include the criteria that the customer team will use to accept or reject the story.

User Story Card-Example

A sample user story card is given here. All user stories contain a user story statement in the form of:

As a role, I want to achieve the goal or desired result, so that I can avail a benefit. An example statement is, “As an employee, I want to purchase a parking pass so that I can park my car safely in the basement and save money.” The role should specify who wants it.

The goal or desire should specify exactly what the user wants and the benefit should specify why the user wants it. Although Agile is not prescriptive and there is no set method to create a user story, the example here displays commonly used elements. Card Name is used for identification. Card Number is used for tracking purposes. Story Points reflect the effort required to code, test, and deploy this user story. It can then be compared with other user stories to determine how big or small it is. Simple estimates are used to manage, resource, and calibrate the project. Value Points reflect the business value of this user story relative to other user stories. Color codes can be used to identify the type of story.

User Story - Examples

Some examples of user stories are given here:

The first one is a user story for a call center agent. It says, “As a call center agent, I want to see the type of broadband connection the customer has in the CRM, so I can offer better choices.”

The second user story says, “As a customer, I want to get periodic updates on the schedule of the booked flight, so I can plan my travel to the airport.”

The third one says, “As a frontline associate, I want to validate the creditworthiness of the customer online, so I can provide overdraft limits.”

Agile Personas

The Agile Persona is a central element of Alan Cooper’s interaction design. A requirement or user story is expressed in terms of the needs of an imaginary user referred to as a persona. The Agile persona can be regarded as a fictitious user playing a role in the customer organization.

While the role is real, the persona is not. It is advisable to avoid matching personas with actual people to prevent real-user needs and preferences from introducing biases in understanding the requirement. Additional personality details help the team to better understand the requirement and visualize the user for whom they are designing a solution.

Some of these details can be:

Likes and dislikes: For example, John, the manager, is a stickler for punctuality. He likes making quick decisions and hence requires the necessary information to be available at a glance.

When, where, why: This explains the context in which the persona is expressing a requirement. Example, Mary, the bank teller, likes to greet each customer personally and serve them promptly, as most of them are senior citizens and dislike standing in lines.

Model and make of car: Stephanie, the Sales Agent who works with high net-worth investors, drives a 1956 Volkswagen Beetle when she is on a field trip.

Job: Steve is a florist at Lake Park Florists, rather than just saying Steve is a florist.

Goals: Timothy, a bank customer, requires a personal loan for a family vacation to Yellowstone. Please take some time to look at the profile of an Agile Persona–Jason, the software engineer.

Creating Agile Personas - Example

This example illustrates the creation of an Agile Persona. Jisc’s Digimap Services wanted to come up with a list of personas to increase usability and user experience. After interviewing different people, five distinct personas based on different user behaviors were distilled.

This activity allowed the team to create a list of features for each persona. The features envisioned were then prioritized and developed. The steps followed for creating Agile personas are:

  • Create a list of tasks for each persona
  • Focus on the core audiences and their goals
  • Avoid potential distractions from issues that are of little benefit to users

Creating Agile Personas - Example (contd)

The five distinct personas distilled from the interviews are shown here: Explorer Evie, Basic Bob, Detailed Dawn, Layered Larry, and Work-around Walter. Notice the differences between each persona’s intent, background, approach, and requirement.

Theme and Epic

Often, the need is felt to group user stories into “Themes” or “Epics”, particularly with larger Agile projects. “Theme” is a set of related user stories that can be combined and treated as a single entity for the ease of estimation and release planning.

For example, “Database Support” may be a theme, which contains stories such as “define a schema,” “migrate existing data,” “modify the code to log into the database,” or “create reports based on data.” By confirming that a set of such stories tend towards the same theme, the team can plan better to deliver the entire theme.

In contrast, an “Epic” is a large user story with low priority. Because of their size, epics cannot be accommodated in a single iteration. At some point in the future, they will have to be broken down into smaller user stories to be worked on in sequence.

Interested in PMI ACP certification? Click to view Course description.

Theme and Epic Example

A travel company wants to launch its e-travel site with features that will enable a customer to login and book bus, train, and flight tickets. Dicksen, the Product Owner, has written all the user stories. He has to classify each of the following as themes or epics:

Customer registration, login activation, customer login, landing page, payments, searching for flights on specific routes, selecting a particular route, booking, and single sign-on to both e-portal and email.

“Theme” is a set of related user stories that can be combined and treated as a single entity for either estimating or release planning. In this example, customer registration, login activation, customer login, landing page, search for flights on specific routes, selecting a particular route, and booking are user stories following a logical order. Therefore, they can be aggregated into a theme that makes the planning and estimation around them easier. Payments and Single Sign-On are huge requirements, and therefore can be treated as epics.


They have to be broken down so that more details emerge. For example, under Payments, there are a number of channels such as debit card, credit card, and net banking. Without breaking the Payments Epic into finer details, it is not possible to deliver this functionality in a single iteration.

Product Backlog

A product backlog contains all the features or requirements, which must be addressed to deliver business value. A product backlog follows the principle of progressive elaboration or rolling wave planning– items in the backlog are elaborated as the project progresses and understanding of the solution improves.

It is maintained by the Product Manager or Owner and is a major input for release, wave, and iteration planning. The product backlog includes functional requirements, non-functional requirements, and product enhancement suggestions from various stakeholders. These are captured in the form of user stories, wireframes, and models. In short, this is a backlog of all the work the team has to perform. The items at the top of the backlog are detailed, while items that will be worked on in the next six to twelve months are defined broadly and imprecisely. A useful acronym to remember while building a product backlog is DEEP, which stands for: Detailed appropriately, Emergent, Evolving, and Prioritized.

Agile Story Maps

Story mapping is an important technique used to visualize the positioning of each user story in the actual use case. In this arrangement, place the story cards or stories horizontally in the sequence the users will need them. Arrange the items vertically and in a sequence based on priority. In the illustration, the stories are in descending order of priority down the vertical axis.

You can further position the horizontal axis such that, the bare minimum features representing the minimum marketable features that will deliver customer value, are just above the axis, represented by the blue cards in this illustration. When the team starts building the system, they must deliver the blue stories as priority features, and also start delivering some of the pink stories, in order of priority. To actually build the system, the team must also deliver a subset of the pink cards. The first row of pink cards represents a basic system. Beyond that, you can add fancier features for further increasing the value. This practice is referred to as “gold plating” in the project management body of knowledge.

Assessing and Incorporating Community and Stakeholder Values

Agile is about delivering value to the customer and delighting customers and stakeholders. This is usually done by engaging the business representatives in the prioritization process as well as constantly involving them in scrum ceremonies, thereby incorporating stakeholder expectations.

Some of the community values to consider are:

  • Vision
  • Servant leadership
  • Trust
  • Collaboration
  • Honesty
  • Learning
  • Courage
  • Openness
  • Adaptability
  • Leading change
  • Transparency

Assessing and Incorporating Community and Stakeholder Values (contd.)

Setting up working agreements with stakeholders helps promote participation and effective collaboration. The four working or operating agreements of the PMI-Agile community are:

  1. All work will be performed against a set of program-wide and team-specific acceptance criteria.
  2. All work teams will self-assign volunteers to fill the community's clearly defined roles.
  3. All work teams will deliver value using Agile artifacts and ceremonies.
  4. All decisions will have team consensus, where consensus is defined as “I can live with that decision”.

Real Life Example

According to the 2011 CHAOS report from the Standish Group, Agile projects are often more successful than non-Agile projects. The report says, “Agile process is the universal remedy for software development project failure. Software applications developed through the Agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.”

In this process, capturing requirements through user stories, use of personas and wireframe, creating product roadmaps, and story mapping act as building blocks in successful software development.


Let us summarize the topics covered in this lesson:

  • Agile Chartering uses a whiteboard or a single piece of paper for the project vision.
  • Agile wireframes are used to represent the layout and design of a software product.
  • User stories are a lightweight mechanism used to capture requirements effectively.
  • Agile Personas can be used to describe fictional users of the system.
  • Agile Story Maps determine the depth of features a product will contain.
  • Agile ensures customer delight and delivers value to stakeholders.


This concludes ‘Stakeholder Engagement: Stakeholder Management and Principles’ tutorial. We will learn more in the next tutorial of ‘Stakeholder Engagement - Agile Communication and Agile Modelling: PMI ACP

Find our PMI-ACP® Certification Online Classroom training classes in top cities:

Name Date Place
PMI-ACP® Certification 8 May -29 May 2021, Weekend batch Your City View Details
  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*