What you will learn here:

• How to identify, assess and actively manage risks at an early stage instead of merely reacting
• Risk management is a continuous process – not a one-off event.
• An open risk culture within a company increases the success rate of projects.

Look forward to the following chapters with important practical tips:

• Risk management definition
• What are examples of risks in projects?
• Risk management example
• What are risk attitudes for projects?
• Risk management example, risk analysis and key tasks
• Risk measures for risk response in projects
• Conclusion – Risk management in project management

First, we will start with the definition of risk management and the assessment of what makes risk management in project management important.

Enjoy reading.

Risk Management Definition

Risk management is a management task in which the risks of an organization are identified, analyzed and later evaluated. To this end, the organization’s higher-level objectives, strategies and policies for risk management must be defined. In detail, this concerns the definition of criteria according to which the risks are classified and evaluated, the methods of risk identification, the responsibilities for risk decisions, the provision of resources for risk defense, internal and external communication about the identified risks, and the qualification of staff for risk management. (Source: German-language Wikipedia)

The worldwide professional association Project Management Institute (PMI) defines “risk” as events with uncertain occurrence. Hence, besides threats the term also includes chances.

Risk management in project management is meant to increase the chances of achieving the project goals. At the same time, the aim is to minimize the risk of project failure. Professional risk management is an iterative process. It requires the constant review of realities, the reassessment and adjustment of measures and plans.

What Are Examples of Risks in Projects

For instance, the following risks might have to be managed in the project environment:

• Economic losses
• Damage to company reputation
• Dangers for health and life of product users
• Schedule delays
• Technical problems
• Definition of project scope
• Resource scarcity
• Quality problems, etc.

Yet, in everyday project management the opposite effect can occur only too quickly: possible high-impact risks go undetected, are forgotten or ignored. Better not to think about what could happen.

Does that sound familiar?

Practical experience has shown that overlooking risks in the project environment is dangerous. This applies even if risk management is not mandatory in your organization. It can get dangerous if health and life, monetary factors or the company reputation are at stake in a project.

The well-conceived establishment of risk management helps lead projects to success.

Good project managers try to identify risks and plan how to handle them.

To what extent project managers actually implement measures and which measures they decide to use depends on the industry and the individual company culture.

By the way: the uncertainty inherent in a project can be a risk factor in itself.

Risk management in projects should take place during the kick-off workshop.

Risk Management Example

Often, undesirable long-term effects are lurking in the shadows, even in cases with seemingly manageable project risks. Here are two short risk management examples:

• Example 1: Essentially, the project for the new development of customer satisfaction surveys was not a big thing. However, later, it became apparent that important questions had been forgotten and now data for evaluation is missing…
• Example 2: The online form generates errors and brings more frustration than satisfaction to customers. This results in more and more of them turning elsewhere…

With risk management and a more mindful approach beforehand, the project participants might have avoided these kinds of risks after all.

For this reason, there are means and methods of effective risk management. In some cases, their use can make or break the success of a project.

Learn what makes projects successful in our article about project success.

What Are Risk Attitudes for Projects?

You can ask yourself this: as a project manager, am I rather:

• Risk-averse (unwilling to take risks)?
• Risk-tolerant (not likely to dwell on risks)?
• Risk-oriented (taking risks consciously)?

Studies have shown that many project managers as a rule are rather risk-averse – except when they have to navigate their project through an acute crisis. Pressure to succeed and be on schedule often do the rest.

In principle, there is nothing wrong with acting cautiously. However, it is important not to miss out on big opportunities for this reason.

The better approach is to analyze risks closely before taking a decision on how to deal with them.

Example: “Is our only reason not to roll out the new software throughout the company that we are unsure about the effects? Or have we assessed the risks carefully and drawn up an appropriate schedule – in other words, do we know what we are doing?”

Our tip: Be aware of both your company’s and your own risk attitude. This should be clear before you plan your risk management in project management. And make sure you communicate any deviations from the standard process actively and with a sound justification for the respective project situation.

Risk Management in Different Industries

Naturally, your industry also plays a vital role in risk management. Highly regulated and often risky environments, such as the finance sector, will always tend to be more cautious. They also have to demand a certain approach from their project managers.

There are industries in which the lives of the users could be at risk in projects and with products, for instance the aeronautical, automotive, or in some cases the construction, industry. They tend to involve calculated risk management for this reason alone. In their case, the responsibility is very high.

Likewise, project managers tend to implement projects carrying a high risk of damage to reputation for the company with more caution than those in which the good reputation is not particularly at risk.

Risk Management Example, Risk Analysis and Key Tasks

Project managers looking to handle risks in a professional way must first ensure they have a full toolbox. Below, you will get to know a few of these techniques.

Task 1: Risk Identification

To identify risks, you need techniques that trigger creative thought processes. You can:

• Check project documents
• Call meetings with stakeholders and experts
• Organize brainstorming sessions
• Create checklists

If that is not enough and there is reason to suspect that several important risks might yet be unidentified, the Delphi method can help.

With the Delphi Method, the project manager surveys a group of experts individually and anonymously. Should there be a stark difference between the responses, you communicate them to all involved. The purpose of this is to spur discussion. You repeat the procedure until the statements no longer diverge as much.

The benefit of the Delphi Method is that it helps you ensure that:

• Everyone speaks their mind openly
• No one is swayed too much
• No one takes a backseat either, e.g. because others may appear to be dominant

Nominal Group Technique: The Nominal Group Technique is used for similar reasons: it works in the same way as brainstorming. However, rather than everyone calling out their idea, they take it down on a piece of paper. Afterwards, you collect these notes. This helps you ensure that quieter voices on your team will also be heard.

SWOT Analysis: If you are working in a project with high uncertainties and are breaking new ground as a team, you might find an analysis of the strengths, weaknesses, opportunities and threats (SWOT analysis) helpful. With the aid of the four dimensions, you consider in which areas you as a company or a project team are good and where you still see potential for improvement. From this, you derive risks for your project.

Pre-Mortem Approach: Another interesting practice has been tried and tested in agile projects: in the pre-mortem, teams imagine their project as failed already and ask themselves what might have happened and why.

As opposed to the post-mortem approach, i.e., the project autopsy after the failure, this event takes place at the beginning of the project. From this, they derive recommendations for action. The intention is to prevent the failure of the project, if at all possible.

Agile, traditional or hybrid? Which method to use for what project. Read now.

Brain scientists were able to prove that the change in perspective (we imagine we were already in the future looking back) leads to participants engaging in scenarios much more closely and creatively than mere predictive brainstorming.

Our tip: Whichever method you end up picking in each particular case: at the end, you should come out with a risk register, i.e., a list of identified risks in your project.

However, be aware that at this stage you may still have unidentified risks. You will not be able to predict all. Use the risk register document e.g. for the communication with stakeholders. Or use it to diminish the risk of losing sight of project risks.

Do not forget to keep checking and updating the risk document at regular intervals. You should also write down strategies for handling each of the risks in the document.

Our tip: To avoid planning redundant measures in risk management, it is worth analyzing the root causes. You may find a common cause for several risks. You could try to fix this and thus master several risks at once.

Task 2: Risk Analysis in Projects and Its Visualization

Your next step in risk management is a qualitative risk analysis in project management.

When Do You Perform a Risk Analysis in Project Management?

Risk analysis identifies risks and opportunities within a project and evaluates and prioritizes them. Analysis takes places after risk identification and is an iterative process which is repeated throughout the course of the project. An effective risk analysis presents all risks threatening the success of a project in a way that is transparent for all project participants. This makes it easier to steer a project in a lower-risk direction.

Thus, risk analysis in projects is a way of evaluating and weighing the identified risks. Thus, you determine their urgency, possible effects and priority.

You can further analyze those risks which you deem to be most dangerous for your project.

For this purpose, there are several detailed diagram techniques, such as:

• The tornado diagram for visualizing the estimated effects
• The Monte Carlo simulation for acting out scenarios with a random generator
• Decision trees for narrowing down possible measures

• With a risk matrix, you visualize active risks in a colored matrix of impact over probability. The risk table makes communication within the project team easier for you. This tool can help you present the risk situation clearly to project sponsors or the steering committee. The graphical visualization in the risk matrix supports project managers in setting priorities and developing response strategies for the risks as will be described further below.

Learn more about reporting and the risk matrix in our project status report article.

Monetary Risk Analysis for Creation of Reserves

When it comes to risks, it is particularly important to keep an eye on possible financial losses and cushion them if necessary. In general, you have the option to calculate the expected value of risks using the formula below. This is the purpose of the monetary risk analysis in project management:

Expected monetary value = probability of a risk (%) * expected financial impact

From this, you can derive possible risk surcharges, i.e. reserves created for identified and analyzed risks.

Top management, on the other hand, maintains more general reserves for anything that might occur without being previously identified.

Our tip: The sooner you address a risk in a project with risk analysis as part of risk management, the more budget-friendly and effective the solution will be. Thus, address risk issues at the very beginning, if a project is of high importance to your company.

Task 3: Planning Risk Measures in the Case of Risk Acceptance

The creation of risk surcharges and reserves is a form of active risk acceptance. You put up with the occurrence of a risk, but not without making provisions.

If the risk does not materialize, the reserves will be released.

Risk Measures for Risk Response in Projects

The following is true of risk management in project management: what type of measure is suited to which project risk will result from the analysis and the actual options in any situation.

Frequent types of risk measures are:

• Avoidance / Prevention (eliminating or evading the danger)
• Mitigation (reducing the probability of occurrence or the extent of the damage)
• Transfer (transferring responsibility to a third party, such as an insurance company)
• Active acceptance (arranging for risk surcharges and reserves)
• Passive acceptance (doing nothing)
• Escalation (asking management for help)

Passive acceptance (outright acceptance without taking action) can be an adequate reaction to some risks for you. Other risks may require the provision of reserves, the purchase of insurance, the involvement of top management or further measures from you.

It is important to make the decisions on the treatment of risks on a carefully considered basis. To this end, you must identify, analyze and judge risks in advance – i.e., live risk management.

Equally important, if not more, is the understanding that it is not enough to look at risks only once at the beginning of the project. Professional risk management is an iterative process requiring constant assessment of realities, reevaluation and adaptation of measures and plans.

Our tip: Give thought to possible risks in your projects on a regular basis. It is not enough to do this only at the beginning! For risks with high impact and high probability of occurrence, you should always have specific measures planned and communicate these openly. And check periodically if these measures are still adequate.

Conclusion – Risk Management in Project Management

This article has outlined why active risk management is useful in projects and which threats it can help avoid. It can get dangerous if health and life, monetary factors or the company reputation are at stake in a project.

In addition, you have become acquainted with several methods for risk identification and assessment, including agile techniques.

Professional risk management in project management is feasible if you know a few tricks and tweaks. And it is worthwhile: if you actively identify, analyze and communicate your risks, irrespective of industry and risk-taking propensity, you will be able to look back on more project success.

Have the courage to approach this topic! It will certainly pay off for you straight away once a theoretical risk becomes reality.

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management. Download the eBook now (just click, no form).

And sign up for our bi-weekly blog newsletter to make sure you receive all our updates.

Is there anything you want to add on the topic of risk management? What gives you a headache? We’ll be happy to respond to your comment below!

About the author:Antje Lehmann-Benz, PMP, PMI-ACP, PSM expert is a trainer for project management with a particular focus on agile practices and Scrum seminars. Furthermore, she has experience as a software trainer (JIRA, Confluence) and consultant. In addition to teaching frameworks and theory, she is experienced in the use of agile games and practical exercises to reinforce the knowledge gained.

Read more about Antje Lehmann-Benz on Linkedin.

Der Beitrag Risk Management in Project Management – Practical Tips and How to Do It Right erschien zuerst auf Blog Project Management for Companies.

The article has the following chapters in store for you:

• Why is control over your project pipeline important?
• Jira tips for your project pipeline
• Multi-project filters
• Dashboards
• Automated reports
• Conclusion: Jira tips for traditional / agile project management

Let us dive in!

Why Is Control over Your Project Pipeline Important?

Projects can develop fast and gain in complexity. When organizing multiple parallel projects, it can also become difficult to keep track of everything and ensure that things run smoothly.

Without an effective method of organizing your project pipeline, such an environment can quickly lead to chaos and frustration for all involved. As a powerful platform for task and project management, Jira can help you in the role of project manager. It supports you in staying on top of your project pipeline.

In traditional and agile project management, Jira allows you to visualize your processes, set priorities and make better use of resources. This enables you to concentrate on the essentials and to maximize the results of your projects.

From beginning to end, Jira makes it possible to see exactly where your project is and which steps are yet to come. This gives you the confidence that you are in control of all aspects of your project and can respond to potential issues proactively.

Find out how 3 Product Owner Jira tips make using the tool really easy.

Jira Tips for Your Project Pipeline

Jira is not only suited to the single project environment. Due to the versatile configuration options of this software, it can also be used for the project pipeline. To this end, you can make use of the board function in Jira.

Using the board function, you can set up any number of boards for one project. In this context, boards are a customizable display of the project information.

As the contents of the board are filtered freely, you can also set up boards across multiple projects. This allows you to map the following use cases, among others:

• One Jira project and several project teams: Each team has its own team board on which only a subset of the information is displayed, e.g. filtered by label or category.
• Several Jira projects and an aggregate board: The aggregate board also displays the contents of all other Jira projects. It is even possible that these Jira projects differ in their project type (software or business) or other properties.
• Team-internal view and view for external viewers: In the team-internal view, all data is shown. With the aid of filters, only subsets are displayed in the view for external viewers, e.g. only tasks with the status “In progress”.
• Requirements management as a higher-level Kanban board: For instance, the requirements are described as Epics. And the teams working on them integrate these Epics via filters into their board.

As you see, there are many different ways to configure Jira for the project pipeline and for multi-project management. Below, you will learn how to set up and use several Jira projects and an aggregate board with the overall status using an example.

Good Practices for Working with Jira in Your Project Pipeline

Multi-project filters

To display the information from several projects on one board, you must edit the board filter. To do this, click on the three dots at the top right of the board or the backlog and then click Board Configuration. In the General tab, open the filter query for the project by clicking on the link Edit Filter Query.

Now, you can edit the filter and, for example, load the Items of multiple projects. In the following example, we are loading all Items from the projects “ST” and “PIPE” in one board. In addition, all Epics from the “Projektplan” project are displayed, provided their status is “In Progress”.

In this place, it would also be possible to filter by assigned team, category, label or other Issue properties. Hence, higher-level but also team-specific or lower-level boards and views can be freely configured.

In the example presented here, there is a parent Jira project listing major requirements (i.e. “Anforderung 123” in the illustration below) and entire projects (e.g. “Projekt A”):

What is more, there is a Scrum Team working on multiple projects and requirements that is presented with both of these as Epics in the Backlog:

Are you a Scrum Master? Check out our 3 Scrum Master Jira tips.

The idea is to work on Epic basis only in the parent project. Therefore, the Backlog Items of the teams involved are not shown. This means that the filter of the PIPE project remains untouched. Yet, once you click on the Epic, you will get to see all linked Items from the other Jira projects, too, in this case the team’s “User Story” (see “Child issues” in the illustration below).

Another interesting read: 7 Multi-Project Management Success Factors

Dashboards

In addition to the option of setting up team-specific backlogs, it is also possible to configure the reports in the dashboard individually. A multi-project view might show the statuses of the Epics, for example, as well as data across multiple projects.

The example shows bugs across all projects and diverse project-specific or team-specific data. You have the options to either create a dashboard for yourself only or share it with your organization or your team.

To do this, click on the three dots in the top right corner and select Rename or share. In the subsequent dialog, you can add viewers and editors of the dashboard.

Important note: Once you have made your selection, click Add before saving the result. Otherwise, the selection will not be applied.

Automated Reports

With the aid of automated reports, you will keep your tasks in view. You can also re-use the filters you previously set up for the dashboard or the multi-project view. For example, if you wish to receive an overview of the open issues by e-mail every Friday, this is how it works:

1. 1. Create filter or use an existing filter
   2. Add a new subscription in the filter details

3. Choose recipients, sending frequency and sending time

With this setting, you can have all possible filters evaluated and sent automatically by e-mail. Thus, you could also create a filter for open issues which have not been updated for X days. This would enable you to send reminders by e-mail to ensure tasks in Jira are kept up to date.

Interested in reporting? Read our articles on the topic:

• Project Status Report
• PPM Report
• PMO Reports

Conclusion: Jira Tips for Traditional / Agile Project Management

Jira is a powerful tool for companies of every size. It is easy to customize and use. Used appropriately, Jira will enable you to plan and manage your projects in traditional / agile project management efficiently and identify problems before they arise.

In addition, it will make collaboration with other people on your team easier for you. The wide range of reports and dashboards gives you a quick overview of the progress of your projects in the multi-project environment. You have received a few important tips for this in the article.

The Blog Series “Jira for Roles in Project Management”

This article with Jira tips for traditional / agile project management is part of a series in which we describe the options Jira and Confluence provide for different roles. Find an overview below:

• Jira for Product Owners
• Jira for Scrum Masters
• Jira Tips for Filters, Dashboards and Reporting (this article)

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management. Download the eBook now (just click, no form).

And sign up for our bi-weekly blog newsletter to make sure you receive all our updates.

Further good tips are provided in the three Atlassian Jira training courses offered by TPG as company seminars that are taught online, partly by the author of this article.

Do you have further questions or comments regarding our Jira tips for traditional / agile project management? Let us know in the comment area.

About the author: Patric Eid has been a freelance trainer, consultant and agile coach for project management with a focus on hybrid and agile project management, Scrum and software training (Jira et al.) since 2013. Previously, he worked in the roles of Scrum Master, (agile) project manager and software developer, and he incorporates this experience into his consulting mandates and trainings.

More on Patric Eid on LinkedIn.

Der Beitrag Jira Tips for Traditional / Agile Project Management – Filters, Dashboards & Reports erschien zuerst auf Blog Project Management for Companies.

This article will shed some light on this key role. It will cover the following topics:

• Product Owner Definition
• Do only Scrum teams have a Product Owner?
• Product Owner duties
• Responsibilities of the Product Owner role
• Qualifications: What must a Product Owner be able to do?
• What is product backlog management?
• Metrics used to measure the value of the product
• Challenges for Product Owners
• Conclusion: Product Owner

Let us get started!

Product Owner Definition

The Scrum Guide defines: “The Product Owner is responsible for maximizing the value of the product resulting from the work of the development team. How this is done may vary widely across organizations, Scrum teams, and individuals.”

Do Only Scrum Teams Have a Product Owner?

The role of Product Owner originated in Scrum. However, many agile development teams have someone who handles the associated tasks – even if they do not use the Scrum methodology.

In extreme programming (another agile approach besides Scrum), for example, there is the role called “on-site customer” or “customer proxy”. Although this person is part of the product development team, their role is to represent the customer when dealing with the developers.

It quickly becomes clear why this role is necessary: most agile teams are working with innovative solutions. They often bear complete responsibility for “their” product, from development to further enhancement and maintenance all the way to its replacement someday. Naturally, the team needs one person to take responsibility for ensuring that this work is heading in the right direction from the start. This person can be the Product Owner.

Product Owner Duties

The person in the role of Product Owner ensures that the product:

• Serves the market and offers solutions to address existing or newly awakened demand
• Retains its competitive standing or, better yet, is ahead of the competition
• Keeps the stakeholders – and especially the customers – happy at a reasonable amount of effort and cost without letting the requirements wish list become endless
• Provides solutions that are truly sensible and useful, with a reasonable amount of effort (applies to internal product development for other departments within the organization)
• Meets the requirements agreed upon by the stakeholders as soon as possible and the development team understands these requirements. Ideally, everyone involved should be able to identify with the solution.
• Can reach a stage of advanced development within the given timeframe, possibly incrementally in the form of agreed intermediate results.
• Delivers quick wins to ensure the necessary liquidity for further development.
• Fulfills internal and external expectations regarding quality.

Find out about 3 Product Owner Jira Tips.

For this purpose, the Product Owner’s key duties are in detail as follows:

1) Set goals and define the vision

• Sets goals and pursue them
  Product Owners must set the overall goals and track these over the long term. The developers, on the other hand, perform the technical work to achieve these goals in iterations.
• Develop a vision for the product
  The stakeholders collaborate with the development team to develop the product vision, which then guides the efforts going forward. (One example: The “BestDoc” app is a platform for finding a doctor, checking their ratings, and booking an appointment. People use it to search for the best doctors in their region. However, it can also be seen as a slogan or something inspiring or motivating.)

2) Involve the stakeholders early and often
To understand the stakeholders’ interests, the Product Owner must also understand the stakeholders themselves. It is the Product Owner’s duty to address these interests and, if necessary, filter them for the development team.

3) Handle the high-level planning

• Plan the iterations in advance
  Prepare the content of the next 1-3 iterations in a timely manner and present the overall plan for achieving these objectives to the team.

• Plan the release packages
  Set the overall objectives and develop an efficient plan: for example, which functionality will go live and when.

4) Measure the success and benefit
Define metrics that can be used to reactively measure the product’s actual benefit and added value.

5) Create and maintain a product backlog
Always keep this overview up to date and refine it or ensure that someone else creates it for the Product Owner.

6) Prepare the sprint reviews
Which key stakeholders will be invited, and what will they be shown? What feedback do you need from them? Which team members are available, and what functionality can they show in the demo?

7) Actively participate in the retrospective
What progress has our team made? Do we have the right tools and processes? How can we improve? The Product Owner as well as the team members pursue team-internal efforts to promote continuous improvement.

Responsibilities of the Product Owner Role

In the contrary, open-ended triangle of the agile environment, it is the Product Owner who bears primary responsibility for balancing and prioritizing the scope, cost, and timing of the product.

Together with the implementation team, the Product Owner is also responsible for making sure that the quality requirements are met. Some of the triangle models consider this as an additional dimension to be considered.

Reading tip: Before starting a project a role clarification workshop can help.

We can therefore say that Product Owners handle many of the duties traditionally handled by project managers.

However, project managers are also responsible for creating the project team, assigning tasks to the project team members, and monitoring their work. They can also be involved in initiating the project, for instance in selecting the projects or doing feasibility studies.

This is usually different for the Product Owner role:

Solution-oriented product perspective

Agile Product Owners take care of a solution-oriented product perspective along the entire life cycle of their product. They think about their product and its users, including operational processes after initial development. In doing so, they detach themselves from pure project thinking.

Initial backlog

An early task of the Product Owner is typically the creation of an initial backlog (the list of all requirements for the product) together with the stakeholders – and possibly the development team or representatives thereof.

Detailed implementation of the product

The undertaking has already been decided e.g. by product management, which in an agile context usually has a superordinate portfolio perspective. The Product Owner, on the other hand, is dedicated to the implementation of a product in detail.

Support from agile coaches

Team development, conflicts, process design and rules for cooperation are the business of agile coaches (in Scrum: Scrum Master). They also help Product Owners with their tasks, so that they always have support when needed.

Consultation / Coordination with the development team

The self-organized development team is responsible for the distribution of tasks. It also takes over the responsibility for quality in the iterations to a large extent. However, the team often has to coordinate with the Product Owner to ensure that it does not deviate from goals, requirements and market realities.

Joint responsibility with the development team

Instead of reporting, the developers show where they stand with regular demonstrations of their work results (e.g. new functions in the product). At the product review for stakeholders, at the end of the iteration, the Product Owner and development team do this again together for everyone outside the agile product team. Together they take responsibility for their own results.

Reading tip: Agile Project Management Certifications – A Comparison

The key responsibility of the Product Owner role is to evaluate and balance various factors such as:

• The cost, profitability, and financial return of the product development against customer satisfaction and marketability
• The often endless list of stakeholder wishes and requirements against the capacity and capabilities of the development team
• The team’s productivity (output) against the quality and benefit of the results (outcome)
• Proactive measures (risk analysis, development of new features, integration) against reactive measures (tests, bug fixes, quality control, maintenance)

Ideally, Product Owners in their role can strike a good balance between these often divergent factors. This is not an easy task, however. To truly understand these factors, the person in this role should possess and use the knowledge and skills that are also important for project managers.

Qualifications: What Must a Product Owner Be Able to Do?

To fulfil his or her responsibilities, a Product Owner should possess the following qualifications, knowledge and skills:

• Profitability calculations
• The ability to ensure that the solution developed provides the expected benefit (benefit engineering)
• Risk analysis methods
• Requirements analysis and prioritization techniques for managing the product backlog
• Stakeholder analysis and a talent for dealing with these people
• Confident manner and good negotiation skills
• An awareness of innovation
• People skills, also in dealing with the development team

The Product Owner must have more skills than just what the Scrum Guide demands of someone in that role.

What Is Product Backlog Management?

The Scrum Guide provides information on this, saying that it involves the following:

“Product backlog management encompasses:

• Documenting all entries in the product backlog clearly and accurately
• Sorting the product backlog entries in a way that optimally advances the goals and objectives
• Optimizing the value of the work performed by the development team
• Ensuring that the product backlog is visible, transparent, clear to everyone, and shows what the Scrum Team will work on next
• Ensuring that the development team has the necessary understanding of the product backlog entries”

Of course, even this list from the Scrum Guide does not cover everything found in practice. However, it was not intended to be all-inclusive. A good Product Owner is someone who manages to handle requirements engineering in an agile context.

Refining the product backlog involves activities such as:

Making decisions about the contents of the backlog

What should be in the backlog and what not? Being able to say “no” to stakeholders about requests that are inappropriate or unrealistic at this stage. A company must respect the decisions of the Product Owner, even if it is sometimes difficult. This also includes: adding new entries as soon as it is necessary and deleting those that have become superfluous.

Making decisions about the types of entries

Functional descriptions, specifications, bug fixes, non-functional requirements such as security, scalability, maintainability? Or the result-oriented solution description from the customer’s point of view (user stories) in one short sentence? The mixture makes sense, since none of these entry types fully meets all the requirements of a product.

Making decisions about requirements and timing

What are the requirements for which iteration and release? Specifically, this is the responsibility of the whole team in iteration planning. Most stakeholders also want to have a say in this. A user story map can be helpful.

Preparing cost estimates

Obtaining rough, relative effort estimates with story points or similar by the team. Because at the product backlog level, requirements are formulated primarily from the user’s perspective. The breaking down into tasks is only done in the iteration planning. The tasks then go into the iteration backlog.

Prioritizing the entries

Normally this is simply a linear list in the product backlog. This means that the priority results from the order: Things that are high up in the list must be implemented earlier than entries further down.

Our tip: Focus only on the backlog’s top entries when formulating and evaluating the entries. The entries at the bottom of the list are less important because these can still change or be omitted entirely.

This strategy, aligned with the “Just-in-Time” principle, helps you avoid wasting energy on requirements that aren’t immediate. It uses the DEEP criteria. This helps you ensure that when working with product backlogs, you follow agile principles and not simply waterfall planning under a new name.

Our tip: If using a flat, linear strategy to prioritize the backlog entries is not sufficient, you can also use User Story Mapping for multidimensional backlog management.

Metrics Used to Measure the Value of the Product

What are metrics to measure the value of the product? This, or something similar, is a favorite question in Product Owner certification exams such as Scrum.org. Initially, it looks like a difficult question. How can we, as a team, measure our product’s value? Certainly not solely based on our productivity. It can be high, but if the results are wrong, it is not helpful.

However, “Evidence-based management” defines several metrics, some of which are still not that well known. Product Owners may find these quite helpful though.

Evidence-based management recognizes four main categories for the individual metrics:

• Current Value: Measures how well the product is accepted and used by the market. It also takes into account the morale of the team developing it. How satisfied are the potential investors?
  Sample metrics: this category includes, for example, customer satisfaction indexes (such as those provided by surveys and product feedback), measurements indicating the relationship between the usefulness of individual functions and how satisfied customers are with these particular functions.
• Time-to-Market: This metric indicates how long it takes from the moment a new requirement is initially formulated until the originator receives the solution. How fast are we able to process new information and make use of it?
  Sample metrics: release frequency, integration frequency, processing times for backlog entries, and lead time.
• Ability to Innovate: This metric indicates how innovative the process for finding a solution is. How innovative is the product and its functionality? Ask this question when further developing a mature system in a large enterprise.
  Sample metrics: benefits of the individual functions in comparison to others, effort or expense of new developments (as a percentage) relative to activities such as maintenance, and amount of time the team is actually spending on the product (as compared to other tasks).
• Unrealized Value: This metric considers the (as yet) unrealized potential. Is it worth taking a closer look at this?
  Sample metrics: market share, user expectations vs. what users have received

Our tip: These metrics are most helpful when they are tracked over a longer period of time because then the developments and trends are more visible.

Challenges for Product Owners

So far, we have taken a close look at the role of Product Owner and a few of the key tools and tasks. Now you will learn about the challenges Product Owners face in their daily work.

Surveys of Product Owners and developers conducted by agile coaches have shown that the main challenges they face are these:

Time pressure faced by Product Owners

Possible problems: the role may not be filled out full-time, but must still be done alongside line work. Too many products and teams have to be managed at the same time. The balance between time for stakeholders and time for the teams is difficult.
Possible solution: cause analysis: what is really the reason for the time problems? What can you change? Are there time management methods that could help? Maybe a reprioritization of projects and requirements would help?

Lack of knowledge about the tasks

Possible problems: the Product Owner knows too little about his own role and agile development. The role is often simply assigned without further explanation or training.
Possible solution: further education, literature such as the highly recommended book “Product Owner: Leveraging Scrum as a Competitive Advantage” by Don McGreal and Ralph Jocham.

Lack of tool expertise

Possible problems: the Product Owner does not know necessary / important documents and metrics for his work.
Possible solution: discussion of tools for creating product visions, impact, story and roadmaps, release planning strategies, evidence-based management, stakeholder analysis tools

Lack of decision-making power

Possible problems: the Product Owner is not authorized to decide. Escalation paths are too complicated and lengthy.
Possible solution: escalation and discussion of such problems on meta level with the management

Problems involving stakeholders

Possible problems: lack of stakeholder participation and interest, conflicts among stakeholders regarding priority setting, too many stakeholders.
Possible solution: stakeholder analysis, learn and apply moderation techniques, requirements analysis together with stakeholders, e.g. with a product vision canvas, involvement of agile coaches.

Problems with the organizational structure

Possible problems: high organizational complexity and silo symptoms
Possible solution: shorten feedback loops with the help of agile coaches

Overly complex projects

Possible problems: projects with many different companies as participants. The Product Owner and the developers belong to different companies.
Possible solution: this does not necessarily have to be a problem, but it is a topic that should be dealt with consciously: contract design and team agreements help.

Highly regulated environments

Possible problems: the environment / industry makes lightweight working methods difficult due to process superstructure.
Possible solution: situational intelligence and concentration on a good error culture and learning as fast as possible in the face of external circumstances.

Products owners cannot ‒ and should not have to ‒ solve all these problems alone. Doing so generally requires the participation of management and all stakeholders as well as good coaching.

Our tip: If you have encountered any of these problems in your organization, it is a good idea to address these issues as quickly as possible by reporting them to the person or office responsible.

Conclusion: Product Owner

In this article, you have learned about the duties and responsibilities of a Product Owner, challenges this role needs to master, the metrics used to measure the value of a product and the specifics of product backlog management.

To summarize, a good Product Owner can make a valuable contribution to the company’s success in the market. This person has a very exciting and influential position offering numerous opportunities. However, the person in this role may also face difficult challenges.

If you are (or wish to be) a Product Owner, get ready for continuous learning involving methodologies, tools, and especially human interaction.

Does this sound appealing? If yes, then go ahead and explore the use of agile methods in your team and with your projects.

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management. Download the eBook now (just click, no form).

And sign up for our bi-weekly blog newsletter to make sure you receive all our updates.

Do you agree with our view of the Product Owner role? We look forward to your feedback, please leave us a comment.

Author: Antje Lehmann-Benz (PMP, PMI-ACP, PSM expert / instructor in Agile Methodology)

Antje Lehmann-Benz, PMP, is a project management instructor with a special focus on agile issues and Scrum seminars. She also has experience in providing software training (JIRA and Confluence) and consulting. In addition to instructing on frameworks and theory, she is also experienced in the use of agile games and practical exercises to reinforce the knowledge gained.

Read more about Antje Lehmann-Benz on LinkedIn.

Der Beitrag Product Owner – Definition, Duties, Responsibilities and Challenges in Agile Teams erschien zuerst auf Blog Project Management for Companies.

Learn how to use these tools to better accompany your processes as well as to determine the team progress.

Look forward to the following topics in this article:

• What tasks of a Scrum Master can Jira and Confluence support?
• Tip 1: Use Quick Filters for the Sprint Board
• Tip 2: Link Retrospective with Sprint Report
• Tip 3: Retrospective template in Confluence and other templates
• Conclusion – Using Jira makes sense for Scrum Team purposes

Let us start with two short definitions.

What Is Jira?

Atlassian Jira is a web-based tool for work management, project management and defect tracking. It is mainly used by teams working in agile project management. Teams using agile approaches are supported by diverse project and board types (e.g. Kanban, Scrum, project management and many more).

Interested in learning to use Jira? We offer online company seminars in English.

What Is Confluence?

Atlassian Confluence is web-based Wiki software supporting internal collaboration in project teams and companies. The tool integrates with Jira perfectly. In this combination, it provides the best conditions for agile teams.

What Tasks of a Scrum Master Can Jira and Confluence Support?

Jira is mainly intended for task planning / work management and maps the situation of different teams well through various project and board types.

Are you a Product Owner? Read our 3 Product Owner Jira Tips.

In Jira, Scrum Teams will find the template type “Scrum” among the software projects.

What distinguishes this template type from for instance Kanban projects is the Sprint functionality. This means that a Sprint Board for planning and implementing work in timed iterations is available.

Within Scrum Teams, Scrum Masters have the particular task to support the processes and team collaboration in the best possible way. They help the organization to better understand and use Scrum.

As a Scrum Master, the special functionalities of Scrum projects in Jira and Confluence provide good opportunities to guide your Scrum Team. Below, you will find three tips which are very important in our view.

Reading tip: Project Management with Jira: All Projects at a Glance 

Let us begin with the Sprint Board.

Tip 1: Use Quick Filters for the Sprint Board

Quick Filters can be found directly above the Board. They allow you to filter the Issues which are displayed on the Board in the form of cards. If a Quick Filter is for example activated for a certain individual (Assignee), the Board will only display those Issues which are currently assigned to that individual.

This provides a good moderation aid: especially in new Scrum Teams, a Scrum Master will often moderate the Daily Scrum Event, at least in a supportive role. The Daily Scrum is a daily gathering to check the progress against the Sprint Goal.

If the Team structures the meeting in such a way as to have every team member tell something about their current issues (i.e. work progress, obstacles, successes), you as their Scrum Master could make their current issues visible to all quickly on a shared screen. To do this, activate the Quick Filter for the person concerned.

Our tip: In your Daily Scrum events, go through the members of your team one by one – and through the Board using the Quick Filters as described above.

Quick Filters for Assignees are often predefined in Jira. In addition, you can set up filters for many other factors yourself – provided you have the Board configuration rights.

Quick Filters for Jira Boards are based on the so-called “Jira Query Language”. You can use anything that you can filter in Jira as a Board Filter, for example different priority levels.

As a Scrum Master, this allows you to ensure that the Board in Team meetings and Scrum events shows exactly those issues on which the Team would like to focus.

To unlock the full potential of Jira, it makes sense to integrate it with your PPM system.

Tip 2: Link Retrospective with Sprint Report

Your area of responsibility as a Scrum Master can also include making agile retrospectives as productive as possible. For example, by moderating them yourself. Or by showing the other Scrum Team members how to hold Retrospectives which will lead to sensible and sustainable improvements in process and teamwork.

Jira supports the work of Scrum Teams with evaluations in the form of reports which are specific to Scrum projects. The Sprint Report in Jira for Retrospectives at the end of a Sprint can help you understand the effectiveness of the work performed.

Once active Sprints are completed in Jira, the software will automatically display a Sprint Report:

Tip 3: Retrospective Template in Confluence and Other Templates

To allow teams to accompany their Retrospectives with moderation and note down their insights, there are different templates in Confluence. If you wish to create a new page in Confluence with the respective template, you can follow the link from Step 3 of the previous tip when completing a Sprint – or simply click on Templates in Confluence.

In a few Confluence versions, the Create button will take you to the templates. Select templates with Retrospective as part of the title.

When editing Retrospective pages in Confluence based on this template, you can make further entries in addition to the metadata, such as page title, date and participants of the Retrospective. You can also specify what the participants have observed in the Sprint that is ending and what suggestions for improvement they have made for the next Sprint.

What is more, Action Items can be recorded and assigned for the specific implementation of these improvements. These will however be tracked in Confluence and not in Jira.

Alternatively, you can also create Backlog entries in Jira for implementation.

Another Retrospective template provided by Confluence, is the “4Ls” Retrospective: it differs from the previous template mainly in the discussion format used. Instead of “Start Doing”, “Stop Doing” and “Keep Doing”, there are four categories:

• “Loved”: what did the team members like most about this Sprint?
• “Longed For”: what else would they have liked?
• “Loathed”: what did they think was terrible?
• “Learned”: what new things did they learn in this Sprint?

In addition, together they can record milestones they find particularly important and group the 4 Ls according to these.

Conclusion – Using Jira Makes Sense for Scrum Team Purposes

For the purposes of a Scrum Team, Jira and Confluence can be invaluable, if you, as a Scrum Master, know what those tools offer you.

In the three tips presented above, you have learned how to guide your Scrum Team more effectively with:

• The right filters in your Team’s Sprint Board
• Sprint Reports for a joint analysis of the Sprint progress
• Retrospective templates in Confluence for moderating and recording your discussion and the agreed improvements

This will allow you to effect more sustainable positive changes in your agile project environment long-term.

The Blog Series “Jira for Roles in Project Management”

This article with Scrum Master Jira and Confluence tips is part of a series in which we describe the options the tools provide for different roles. Find an overview below:

• Jira for Product Owners
• Jira for Scrum Masters (this article)
• Jira Tips for Filters, Dashboards and Reporting

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management. Download the eBook now (just click, no form).

And sign up for our bi-weekly blog newsletter to make sure you receive all our updates.

Do you have further questions or comments regarding Scrum Master Jira use? In that case, please write to us in the comment area.

Author: Antje Lehmann-Benz (PMP, PMI-ACP, PSM expert / instructor in Agile Methodology)

Antje Lehmann-Benz, PMP, is a project management instructor with a special focus on agile issues and Scrum seminars. She also has experience in providing software training (Jira and Confluence) and consulting. In addition to instructing on frameworks and theory, she is also experienced in the use of agile games and practical exercises to reinforce the knowledge gained.

Read more about Antje Lehmann-Benz on LinkedIn.

Der Beitrag 3 Scrum Master Jira / Confluence Tips to Improve the Way You Work with the Tools erschien zuerst auf Blog Project Management for Companies.

This article will give you an overview of the professionional situation of women in project management (statistics and experience). You will also learn more about specific measures to increase the proportion of women in project management:

• Definition womenomics
• The female project manager – the current situation
• Is project management a man’s world?
• A salary comparison for women in project management
• The positive influence of women on projects and companies
• Greater diversity in project management
• Tips to get more women into project management
• Conclusion – Womenomics: Gender pay gap and the role of women in project management

Let us begin!

Definition Womenomics

“Womenomics” – the female shift in business – is a global megatrend that has too long been neglected.

Japanese late prime minister Shinzō Abe coined this term in 2013 by declaring his intention to focus more strongly on the Japanese leadership’s stated goal of making equality for women the centerpiece of Japan’s economic and growth strategy. His stated goal at the time was to have women occupy 30% of the managerial positions. Additionally, the workforce participation rate for women aged 25-44 was to be increased from 68% to 73% by 2020. The goal: to tap the latent reserves of the female labor force as a production factor to boost economic performance and development.

Maximizing the economic potential was not the only goal, however. Workplace equality, and especially career opportunities, are not only an economic and business issue but even more so a societal one. Can a nation or a company really afford to neglect 50% of its workforce, especially one that is generally very well educated?

No society can justify denying half its population equal opportunities for development. Gender diversity is no longer a niche issue. It is now part of the political and economic mainstream and has become a major issue in decision-making processes. So now the question is, how have gender diversity and womenomics affected project management?

The Female Project Manager – The Current Situation

Data on the involvement of women in project management is sparse, to put it mildly. Statistics available from the Project Management Institute (PMI) show that women currently constitute an estimated 20-30% of the project management staff worldwide. Another study produced by the Germany-based “Gesellschaft für Projektmanagement (GPM)” (German member of the International Project Management Association, IPMA) from 2014 came to a similar conclusion, estimating that roughly 30% of the German project managers were female. However, there is good news: the percentage is increasing: in 2024, the GPM found that the female share of project managers had increased by 44% compared to their last survey from 2019.

Most of these women migrate to project management rather accidentally. In other words, few of these university graduates originally sought a career in project management. The majority began their career as a technical expert and over time progressed into the role of project manager.

This progression in perspective and responsibility is generally accompanied by professional development opportunities. As women begin to assume responsibility for projects, they also work to obtain the associated professional qualifications, for example, through certification programs.

There is a high degree of job satisfaction: These women value the:

• Fact that each project is unique
• Joy of working with others to achieve a goal and produce clear results
• Collaboration with a variety of teams and clients

Is Project Management a Man’s World?

Gender-specific challenges – obstacles – have not been completely eliminated. Project management remains a man’s world.

Women managers often report that they first have to assert themselves to gain acceptance and overcome the typical stereotypes.

There is also a scarcity of female role models. This is partially attributable to the fact that more women than men face the challenge of achieving a good work-life balance while managing a project.

A Salary Comparison for Women in Project Management

Project management work is lucrative for women as well – but not as lucrative as for their male colleagues. In 2024, the Gesellschaft für Projektmanagement (GPM, see above) published their eighth study of project management salaries and careers.

Project managers who were men had an average salary of €112,000 (€87,000 in 2019). Their female counterparts earned approximately 21% (11%  in 2019) less.

The PMI salary report for 2020 determined that the pay gap for Germany is higher than the GPM for 2019, namely 16%.

This gender pay gap increases with the level of responsibility and seniority. At the highest levels of project management, this gender pay gap is an immense 26.3%, whereas women are only subjected to a 4.7% reduction for entry-level positions.

An intuitive explanation could be that women and men are subject to the same demands and qualifications as they begin their careers. The gender pay gap that then emerges could be due to women choosing to pause their careers to raise a family and the consequent decision to devote less time to their careers.

However, there may be other obstacles for women seeking to advance their career: the reluctance to be in the limelight and assume greater responsibility – both prerequisites for a managerial position.

An international comparison shows the following gender pay gaps in project management:

• Great Britain: approx. 14%
• France: 11.5%
• USA: 10%
• Switzerland: 5.5%
  (This is notably the country with the highest project manager salaries for both men and women.)

The Positive Influence of Women on Projects and Companies

The employment world continues to evolve and is developing into a project-based economy.

The percentage of project-related work in the total value added was already approximately 40% in Germany for 2019. Forecasts predict the global demand for project managers to grow by 33% before 2027.

The key to gaining a competitive advantage in this brave new world of work is having highly efficient, motivated employees. This is a prerequisite for successful projects.

Having qualified women in project management will therefore become increasingly important. They have already proven their worth and are therefore no longer an optional nice-to-have but rather a valuable contributor to the company’s bottom line. There is a good business case for including more women in project management.

Greater Diversity in Project Management

It is a well-known fact that diversity in project management – also regarding gender balance – produces better project results and serves to sustainably incorporate the project in the affected company or organization.

Women can deploy their strengths in projects by:

• Bringing people together and driving the collaboration needed to produce a shared achievement
• Finding fast, practical solutions to complex problems
• Their ability to communicate well

Especially the latter, good communication skills, is a critical asset in project management.

You may also find this article interesting: Resource Management in Project Management – Basics and Methods for Beginners

Tips to Get More Women into Project Management

You, too, can help further increase the percentage of women in project management. And now, a few striking examples to illustrate some best practices:

Raising Awareness of the Scope of Activities Handled by Women Project Managers

There should be clear communication of the scope of activities and valuable contributions made by women, in particular. Many women, and especially younger ones, are still awaiting more comprehensive answers to these questions:

• What is a typical day for a woman project manager?
• What are the benefits and challenges?
• How can I become a project manager?

In addition to the efforts by the PMI Institute, IPMA, and GPM to answer these questions, we also recommend the “Celebrating Women in Project Management” initiative launched by the Australian author Elise Stevens, who serves as a valuable role model. Stevens presented successful women in project management 150 days a year on her social media channels.

In her book, Sarah Ipek Ozguler interviews 29 women project managers around the world to illustrate their successful career paths. It is also a valuable source.

Those aspiring to be project managers can benefit as well from using personal branding to promote themselves and their profession.

Creating and Promoting Networking Opportunities

Women project managers want to, and must, network and share ideas with other members of their profession in order to learn from each other and help each other.

In Germany, this networking and support opportunity for women project managers has been provided chiefly by GPM and its female PM experts.

Companies can, and are encouraged to, provide similar forums for sharing ideas and internal networking within their own organization as well.

In addition to networking, women project managers can also develop a mentoring program (that can also be non-gender-specific). Mentoring involves much more than just networking; it offers new opportunities to learn from one another and grow professionally.

In Germany, there are now several mentoring programs, among which Mentorme is surely the largest and most successful community.

Conclusion – Womenomics: The Gender Pay Gap and the Role of Women in Project Management

Although there have been promising developments, when it comes to getting “more women into project management” much more still needs to be done. This was also the tenor of a 2022 German-language study on women in project management conducted by author Darya Schwarz-Fradkova and TPG The Project Group.

Hopefully, the hitherto barely tapped resource of womenomics will be used and receive the recognition it deserves.

This is the only way to utilize this megatrend’s hidden potential to bring economic and societal development to full fruition – even far beyond project management

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management. Download the eBook now (just click, no form).

And sign up for our bi-weekly blog newsletter to make sure you receive all our updates.

Have you dealt with womenomics in a project environment, and what do you see as the advantages and disadvantages? We would enjoy hearing from you. Please leave your feedback in the comments section.

Sources used

Article:

• Frauen erobern die Arbeitswelt (Women Conquer the Workforce)
• Womenomics und die japanische Realität (Women and Japanese Reality)
• Women in Project Management: Future Perspectives
• Women Project Managers: the exploration of their job challenges and issue selling behaviors

Studies:

• PMI: Earning power, Salary Report 2020
• GPM Salary Survey (2024)
• PMI: A case for diversity (2020)
• Studie zur aktuellen Situation von Frauen im Projektmanagement der GPM (2014) (Study of women’s current situation in project management)
• PMI: Pulse of the profession (2020)

Books:

• Ozguler, Sarah Ipek (2019): The Perspective of Women Project Management Professionals

Der Beitrag Womenomics – Gender Pay Gap and the Role of Women in Project Management erschien zuerst auf Blog Project Management for Companies.

Look forward to the following topics in this article:

• Responsibilities of a Product Owner
• Tip 1: Writing Stories that will not last
• Tip 2: Acceptance criteria for good Stories
• Tip 3: When it is getting too much: split Stories
• Conclusion: Using Jira as a Product Owner is easy, but …

However, before starting on the responsibilities and tips for the Product Owner, it makes sense to get an overview of the different Atlassian Tools. Let us clarify first what Jira and Confluence are.

What Is Jira?

Atlassian Jira is a web-based tool for work management, project management and defect tracking. It is mainly used by teams in product and software development. It supports agile teams with different project and board types, for example:

• Kanban
• Scrum
• Project management
• etc.

Interested in learning to use Jira? We offer online company seminars in English.

What Is Confluence?

Atlassian Confluence is web-based Wiki software supporting internal collaboration in project teams and companies. The tool integrates with Jira perfectly. In this combination, it provides the best conditions for agile teams.

Why Have Special Product Owner Jira Tips?

By now, the role of Product Owner is used in many projects – even those not based on the Scrum framework but merely using some elements of it. The scope of the Product Owners’ tasks differs from company to company, since Scrum is not used consistently.

Jira, on the other hand, is a work management software used by 14,000 Atlassian customers worldwide. Consequently, it is widely used, both in traditional constellations and in modern project management organizations.

As a Product Owner, you can hardly get around the use of digital tools nowadays. Jira being the current world market leader for work management, we will concentrate on tips for using Jira in this article.

You might also like our article about the Role of Product Owner in Agile Teams.

Responsibilities of a Product Owner

As mentioned above, it varies from organization to organization what tasks a Product Owner takes on. However, the following tasks are often part of the responsibilities of the role:

• Recording and coordinating requirements
• Representing stakeholders in the team
• Communicating internally and externally
• Product and project marketing
• Defining the roadmap
• Describing WHAT is to be implemented
• Prioritization and budgeting
• Focusing on product development and integration into corporate strategy

Most of these points can be implemented with the aid of Jira. The focus of Jira is on formulating the requirements and creating the roadmap.

Now look closely at the list once more. Do you notice anything? There are hardly any differences between the requirements for the Product Owner and the role of project manager. However, the focus for the project manager is more on the project and its successful implementation. This is different for the Product Owner: the focus of the role is on ensuring that the product is successful in the long term and that it fits the overall strategy of the company.

Find out how project management with Jira works in this article.

3 Tips for Product Owners

Recording requirements, describing the WHAT, prioritizing and creating a roadmap: all of these are tasks you can map in Jira as a Product Owner. Even if you do not do this yourself but have delegated the task to the team, the following tips are bound to help you.

Unsure what approach to use, agile, traditional or hybrid? Our article comparing project management methodologies may be just right for you.

Tip 1: Writing Stories That Will Not Last

Writing Stories in Jira is very easy. Yet, the challenge is to write good Stories that the team will understand and that include what the stakeholders want.

Therefore, why write Stories that will not last?

A Story serves only one purpose: implementing a requirement or a request. It is not designed for documentation, though it is used for documentation in some companies.

What Are Requirements?

Requirements are functional and non-functional specifications, requests and ideas. In most cases, the requirements are unclear at first and develop over time. Once they are specific enough, they can be recorded as a Story in Jira.

Where Else Are Requirements Described?

As a rule, you can always use Stories.

However, it can also make sense to describe requirements in Confluence first and then align them with the stakeholders. Subsequently, one or several Stories are created from one requirement. Jira as a tool lends itself to this. Yet, it is important to remember linking the Stories in Jira with the requirements in Confluence.

What Are the Benefits of Using Confluence?

If you describe the requirements in Confluence, you have also found the appropriate location for documentation. Confluence works better for structured storage of information.

Jira is short-lived. Once a Story is completed, it disappears from the visible area and must be searched for to be seen.

How Can This Be Further Structured?

By default, Jira works with so-called Epics. An Epic is a big Story. In Jira, this is depicted as a structural element. Under an Epic, you can subsume several Stories. The requirements structure can look like in the following example.

The structure usually looks like this:

1. One to several Epics can be created from a requirement in Confluence.
2. Under an Epic, there can be Story, Bug and Task.
3. Stories and Tasks can again be divided into Sub-Tasks.

How Are Stories Used?

Stories are used to describe customer benefits. Over the last few years, a template has been established for describing User Stories:

As a [role] I want [feature] so that [value].

Example: As the author of the blog post, I want to convey the writing of Stories so that Product Owners are supported in their daily work.

How Are Stories in Jira Presented?

Three fields are mandatory in Jira: Project, Issue Type and Summary.

The template mentioned above is entered in the “Description” field. For our example, this means:

However, the introductory text alone will not be enough to implement the Story. In the case of the blog post, we still need:

• Keywords of the post
• Length of the post
• Images of the post
• What tips should be described

This means, as a Product Owner, you must provide additional information to describe the Story. To achieve this, you can just add further information in the Summary or as an attachment.

One way to enter further information is in the form of acceptance criteria.

Tip 2: Acceptance Criteria for Good Stories

The acceptance criteria have been added to the example described above:

In the example, three acceptance criteria have been recorded in the Description.

• Writing Stories, acceptance criteria and splitting Stories have been described
• Post length of about 1,500 characters
• Paragraphs do not exceed 3 to 4 sentences

As an alternative to entering the criteria in the Description, you can also use a To-do plugin. In this case, the acceptance criteria are presented as individual entries you can also tick off.

Tip: A suitable plugin for recording acceptance criteria in Jira is e.g. Acceptance Criteria for Jira by HeroCoders.

To start working with Jira acceptance criteria, however, the Summary field is sufficient.

Tip 3: When It Gets Too Much: Split Stories

Even when using the hierarchy described above, some Stories will be too big. But what exactly does too big mean?

If a Story is too big, it will not be possible to implement it in a reasonable timeframe. Likewise, estimating its effort or complexity will be difficult to impossible.

If you are a Product Owner working according to the Scrum framework, your benchmark is a Sprint. A Story should be described in such a way that it can be implemented within a Sprint.

Interested in Jira tips for Scrum Masters? Read article Jira for Scrum Masters.

If you work without Sprints, you can work out with your team how extensive a Story should be at maximum. Most teams agree that Stories should be completed within 2 weeks.

How Do I Split a Story in Jira?

To split a Story in Jira, you can use the split function. Right-click your Story in the Backlog, and then click Split issue in the context menu that opens.

As a result, the below dialog box will open:

For our example, we want to treat proofreading (“Korrekturlesen” in the example) and publication (“Veröffentlichung” in the example) in separate Stories. Both Stories include further tasks. For instance, publication also involves adding links to the blog post and including the post in the page structure.

For our original Story – creating the blog post – this is no longer relevant. We can consider the creation of the post as done, even if the blog post has not yet been published.

This is how you can divide a story into meaningful sub-steps.

How Can the Story be Split in a Meaningful Way?

In the previous example, the division was made from a logical point of view. We have three Stories based on the publishing process:

• Writing the post
• Proofreading
• Publication

However, writing the post could also have been split into several Stories. For example, into:

• Writing the introduction
• Writing of Tip 1
• Writing of Tip 2
• Writing of Tip 3
• Integrating the images
• Writing the conclusion

This would have been a division into individual work steps. This is, for instance, an option when different teams are working on a Story. Or when a part is planned for one Sprint and the rest only later. In this way, the post could be created over several Sprints, and the Stories could be completed individually.

The Story could also be divided functionally, e.g.:

• Writing a post with Jira Product Owner tips
• Research for suitable images

In this case, the Story is split into the actual writing and the image research. Applied to a software project, this would mean:

• Implementing the backend functionality
• Implementing a frontend to operate the backend

As you see, there are many ways and possibilities to split a Story in a meaningful way. Discuss with your team what would work best and be most helpful for you.

How Do You Present Dependencies?

If you have split a Story, this is visible in both the original Story and the new Stories:

Via the Board configuration, you can also display dependencies in the Backlog (or even on the Board) in text form. To do this, go to the configuration (Board Settings) at the top right:

Go to Card layout (1) and then add “Linked issues” to the Backlog view (2). Please do not forget to click on “Add” (3) as well.

If you return to the Backlog now, the dependencies will be displayed below the Summary.

Thus, you will see the dependencies of Stories in text form below each other.

Conclusion – Using Jira as a Product Owner Is Easy, But …

The tips mentioned above make it easy to use Jira as a Product Owner. Stories are quick and easy to create as well as structure. In combination with Confluence, requirements can be recorded in a transparent and sustainable way.

By describing the Jira acceptance criteria, it becomes clear what a Story must contain. And if several people are working on a Story, or a Story simply becomes too big, there is an easy solution: simply split it into several Stories.

Yet, as with many things: the devil is in the details.

The Blog Series “Jira for Roles in Project Management”

This article on Jira and Confluence is part of a series in which we describe the options the tools provide for different roles. Find an overview below:

• Jira for Scrum Masters
• Jira for Product Owners (this article)
• Jira Tips for Filters, Dashboards and Reporting

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management (PPM). Download the free eBook “The PPM Paradise” now (just click, no form).

And sign up for our bi-weekly blog newsletter with information on more practical articles, eBooks, etc. to improve your project management maturity level.

Are there any Product Owner Jira tips you feel we have missed? In that case, please write to us in the comment area.

Der Beitrag 3 Product Owner Jira / Confluence Tips to Improve the Way You Work with the Tools erschien zuerst auf Blog Project Management for Companies.

• How cross-corporate collaboration works
• The advantages and disadvantages of how the roles are distributed
• How to write an agile contract that protects everyone involved in this collaboration

Here you will find a collection of different contract models specifically for use in agile project environments.

Let us begin with an overview of the chapters:

• How do agile teams work?
• What is a “product owner”?
• Contract model for agile projects: Who chooses the product owner?
• Overview of agile contract models
• Other forms of hybrid and customized contracts for agile projects
• Which contract type is most suitable?
• Conclusion – Agile contract models

How Do Agile Teams Work?

We will start with a quick review: an agile team – often a Scrum team – consists of a product owner, a Scrum master and three to nine developers. The team uses iterations, called sprints, to focus on the development of a new product or the further development of an existing one. Each product increment should be ready to be demonstrated and potentially delivered by the end of each sprint.

Development cycles should last no longer than one month. The product owner defines the stakeholder expectations. The Scrum master acts as team coach and process owner, and helps teams not yet familiar with the new rhythm of this type of development.

What Is a “Product Owner”?

An agile team does not have to be a Scrum team. It can simply be a group of people that work together using Kanban. It can also be a team that employs hybrid elements and combines agile and traditional procedures.

In any case, there is normally one person who bears responsibility for clarifying, documenting and communicating the requirements. This role is often called “product owner” even in non-Scrum teams.  However, “requirements engineers”, “business analysts” or simply “customers” can also assume this role. For simplicity’s sake, we will refer to this role as “product owner” in this article.

Contract Model for Agile Projects: Who Chooses the Product Owner?

Cross-corporate Scrum teams are actually the norm and might even be considered more common than single-company teams. Many agile teams are therefore faced with the challenge of implementing the Scrum team’s rules and ideals without having the corresponding guidelines.

Further reading: What Is a Product Owner & What Is Their Role in an Agile Team?

The first step is to clarify which of the contracting parties chooses the product owner. This is important with regard to the customer collaboration over contract negotiation and involves asking the following questions:

• How good is the relationship between the client and the supplier? Will the product owner representing the customer be able to work closely enough with the development team and able to guarantee that he / she will be available as much as needed? And: Do the product owner and the developers trust each other, or is there an air of mistrust?
• Who knows the stakeholders well and understands their needs? Who really understands the market? This should generally be the company commissioning the work.
• On the other hand, who knows the development team well and is familiar with its methods?
• Who is best able to translate and prioritize the client’s requirements at the implementation level?
• How knowledgeable about agile methods are those involved? Is there someone on either side who has experience with being a product owner?

The arguments for having the product owner be someone on the supplier side are:

• Technical skills
• Proximity to the implementation team
• Familiarity with internal development processes

On the other hand, the arguments for having the product owner be someone on the client side are:

• Proximity to the market, the end customers / stakeholders, the requirements
• “Power” or authority through their position as a paying client

Our tip: The best strategy is to discuss the distribution of roles with the contractor and client already during the contract negotiations and then document this in the contract. It becomes even more essential to clearly define the distribution of roles if you decide that the product owner responsibilities should be divided between the contracting parties. We cannot emphasize this enough, because some of the most severe conflicts involving multiple companies occur in projects where the roles were not clearly defined. This can often have legal repercussions.

Another interesting read: 3 Important Jira Tips for Product Owners

What Is a “Proxy Product Owner”?

In addition to selecting a product owner from only one of the contracting parties, there is also the option of choosing a hybrid solution. This person would then be, for example, a “proxy product owner”. In this case, there is a product owner from the contractor company and one person from the client company who acts as a liaison to the client.

However, the proxy product owner is generally in a weak position, and therefore has little decision-making authority. This person basically serves as a filter with regard to the requirements.

These and the other characteristics constituting the typical challenges facing a product owner are described by Roman Pichler in his blog article “Avoiding Common Product Owner Mistakes”.

Our tip: People finding themselves in the role of proxy product owner and facing problems should try to resolve the situation, as that is the only solution. The person should be granted the authority needed to be a “true product owner”, including the authority to make product-related decisions and set priorities, or the role should be given to someone with that authority. At the very least, clearly describe the roles and delineate decision-making responsibilities for them, with an emphasis on communications and alignment between them. Role conflicts will otherwise endanger any efforts to set priorities in the product development.

Other Factors You Should Consider in a Contract Involving Agile Projects

OK, you have now solved the challenge of who is the product owner? Great! Here are a few other things that should be considered in agile contract management:

• Shared interests and a partnership based on the principle of good faith should be documented in writing.
• It should be clear to everyone what assumptions and leadership principles will prevail in the project.
• Stakeholders at the client’s company should regularly participate in meetings to discuss the details.
• The development team should be able to organize itself within the given framework. The team members are the technical experts for the implementation.

Overview of Agile Contract Models

The following sections describe the various contract models that can be used to write a contract for agile development services. It also discusses the billing practices for each type of agile contract.

Fixed-Price Models

For clients, fixed-price contracts minimize the risk that costs will exceed the budget. However, there are a number of problems with this model for agile projects. Some feel that fixed price contracts are not suitable for agile projects for the following reasons:

1. Not being able to adequately alleviate the risk of missed deadlines or that a product is developed that proves useless for the client.
2. The use of agile methods requires development that strongly focuses on the client’s needs. However, it is very difficult to reach an agreement on the fixed price if the overall functionality has not even yet been defined.
3. A fixed-price agile contract often only defines the time frame in which the initial product will be developed. Everything that happens after that point (further development, maintenance and support) is initially ignored.

The following document workflows are often used in such contract processes:

Specifications normally contain important information for the client and are part of the call for bids available to possible bidders. As soon as the collaboration has been agreed, these bidders develop a detailed description of the content and scope (performance specifications or similar). Sometimes this is prepared using a template provided by the client. For agile projects in which the requirements are to be “discovered”, these descriptions can actually hinder innovation. In this case, a more “lightweight” document like a product backlog can be used.

Fixed Price with Several Agile Elements

To adapt a fixed-price model to be more suitable for agile projects, you will have to include several agile principles in it. The following factors can be considered:

1. Functions are not completely defined in the beginning. Each of the contracting parties confirms to the others that they understand this fact.
2. There is mutual agreement on the project goals, specifically that there is a shared vision of the product and a roadmap. There is a contractual obligation to continually share information via discussions, and not only by sending documents back and forth.
3. If problems arise, cooperative approaches are used to solve the problem and the “agile mindset” is emphasized to reduce differences and find common ground. This demands trust and empowerment among all those involved. A reference to an existing approach can be contractually documented. For example, there can be a reference to a Scrum guide if the team uses this as a framework.
4. The completion criteria (Definition of Done) agreed upon by the implementation team together with the product owner and stakeholders can also be included in the contract. However, you should emphasize that these criteria might change during the course of the project. The contracting parties must understand what exactly a Definition of Done is, how this differs from acceptance criteria, and why this represents a team agreement. Acceptance criteria can also be defined in the contract and serve as a basis for the Definition of Done. Lastly, defined timeboxes for iterations (called “sprints” in Scrums) and meetings (and their frequency) can be written into the contract as well.
5. Clarification of Roles and Team Charters are other documents that can be included in fixed-price contracts adapted for agile projects.
6. In lieu of a scope statement or performance specifications, there can be a contractual agreement on the necessity of a product backlog.
7. Roles are clearly defined for the project and documented in the contract. Also documented is who should participate in which meetings. For example, the contractor and the client can each send a representative to the sprint planning meetings to prevent contractual and unpleasant surprises.
8. Estimation methods can be used in the way that works best. You are not required to use agile sizing and relative effort estimations. This is especially true when there are existing methods that have been proven effective. The parties can devote more time to agile estimates if they feel that these would benefit the project. Of course, the parties can also contractually agree to use product or release burndown charts to measure progress.

Prioritization in Agile Projects

If the estimates prove to be wrong and problems occur, you need to react. In the worst-case scenario, the project must be prematurely terminated. Otherwise, the service provider must make provisions and reevaluate the project portfolio’s priorities to compensate for any problems that affect the project in order to safeguard its own liquidity.

A good strategy is to evaluate the incoming requirements with regard to risk vs. benefit as follows:

Accordingly, more risky work should be completed earlier than other work. This gives you a greater range of options at a time when the incurred expenditures are lower.

Need more information on agile PM? Read about the agile retrospective.

Agile Fixed-Price

The examples described so far serve to gradually introduce agile principles in traditional environments and agreements. You also have the option to make the entire contract more “agile.”

With the “agile fixed-price” model, you first describe the contractually agreed project scope as based on the product vision and provide a very rough description of the features.

Those involved then estimate the overall effort using story points and translate these into person-days. This is done, for example, by simulating the first sprint-planning meeting to provide a reference point.

As a safety precaution, the project can still be canceled at this point if you determine that the effort required is too great. Agreements are also reached on the distribution of risk among those involved in the project. Contractors can obligate themselves to realize all the “must-haves” and only develop additional features if the budget permits it.

A special type of contract for agile projects in this context is the ”Money for Nothing, Change for Free” model of Scrum co-inventor Jeff Sutherland. In this case, the client initially follows the traditional course by defining the requirements, and the bidder then responds by submitting a bid at a fixed price. As the implementation begins, the client assumes the role of product owner and manages the product backlog.

At each sprint review meeting in which the service provider presents the results of the previous iteration, the client − as is typical in Scrums − provides feedback and revises the product backlog. However, the fact that this is a project with a fixed-price contract makes it special in that there is an agreement that: for each new requirement added to the backlog − in the form of a user story − a requirement with a comparable level of effort must be removed from the backlog. This is the “Change for Free” part of the contract model.

Another unique characteristic is the “Money-for-Nothing” principle. This applies to cases in which the bidder and service provider agree at some point to end further development of the product and terminate their collaboration on this topic. If there is money left in the original budget at this point, the contracting parties split this money in accordance with the percentages previously defined in the contract.

As innovative as this “Money-for-Nothing” principle is, and despite it being so compatible with the agile development environment, there is still a problem in that the existing processes in most companies do not allow any remaining budget to be distributed.

The “Change-for-Free” idea, on the other hand, has proven to be successful in actual projects.

Fixed Price: Payment per Sprint

You can also make your basic contract more agile by reaching an agreement on a payment cycle aligned with the sprint rhythm − hence, a fixed-price per sprint. In this “fixed-price per sprint” model, the contracting parties essentially have many small fixed-price projects, whereby each iteration represents a mini-product. Each sprint plan leads to a new contract and each review represents an acceptance meeting. The time frame of each sprint is thereby clearly defined. Similar models are frequently used by U.S. regulatory authorities, where they are known as “Blanket Purchase Agreements” or also “Indefinite Delivery / Indefinite Quantity” (IDIQ) contracts.

Time & Materials (T&M)

In a Time & Materials contract, the client obligates itself to pay the contractor in accordance with the time spent on the work and the materials used. This type of contract is very suitable for agile project situations that lack very detailed information, especially initially.

However, it is vital that the contractor not take unfair advantage of this situation, and remain honest and truthful in documenting the incurred expenses. The contractor also has less incentive to work effectively. If there is a dispute and the two contracting parties in a T&M project go to court, there is another potential problem in that the relationship could be interpreted as a form of employee leasing.

One solution could be to adapt the T&M contract to create a “Design to Cost” or “Pay per Productivity” contract.

• “Design-to-Cost” contracts have a fixed budget but a more flexible project scope. This type of contract is especially well-suited to situations where the contractor is able to propose price amenable to them based on their prior experience with similar projects.
• In a “Pay per Productivity”contract, the contractor contractually obligates itself to a specific productivity rate based on the agreed criteria. The objective is to provide an incentive to maintain a high standard of product quality. A large portion of the paid productivity is otherwise spent on simple maintenance and rectifying problems. However, this model does not really focus on the client benefit because the teams could theoretically be working very effectively on functionality that does little to benefit either the client or end-user.

T&M: Payment per Sprint

The “Pay what you get” model is similar to the “fixed-price per sprint” one. However, there is an explicit agreement that the client will only pay for the deliverables accepted in the sprint review. This works if there is a high degree of trust between the contracting parties.

Otherwise, it generally does not work because the supplier is required to provide the goods and services in advance for the duration of the sprint before getting paid.

Want to get certified? Learn about agile project management certlifications.

Other Forms of Hybrid and Customized Contracts for Agile Projects

There are numerous other hybrid and customized contracts in addition to the most common ones: fixed-price and time & materials. Past experience with agile projects has shown the following ideas to be among those feasible:

Benefit-Oriented Contract Models

Developing a value-adding product is one of agile development’s key objectives. None of the contract models presented so far helps to ensure that this objective is achieved. Legal experts are therefore often relatively unfamiliar with these contract principles. However, these can hold the solution for dealing with the high degree of complexity and uncertainty in today’s software projects.

Cost-benefit relationships must be continually monitored when using such contractual agreements. It must be possible to ensure a reasonable balance between effort and result over a longer period of time.

Benefit-Oriented Award Agreements

There are contract models in which the client pays a relatively small daily rate intended to cover the contractor’s costs. To enable the contractor to make a profit, an award is paid whenever an agreed value-in-use goal is reached.

In this case, it must be clear to all involved what the client considers “value” and how this is measured. This is done using impact maps.

“Pay per Use”

Value-based payment agreements, such as many of today’s SAAS solution licensing models, are also considered value-in-use contract models. These are also suitable for agile projects.

Handpicked Content: Read more about how agile methods can make resource management succeed: Agile Resource Planning – Can It Reduce Resource Conflicts in Projects?

Which Contract Type is Most Suitable?

Conclusion – Agile Contract Models

Projects are unique, temporary endeavors. No single contract model is the best one for every possible project. The project manager and everyone else involved in the contract negotiations must work together to find the model best suited to the situation and environment of that particular project. This is especially true for agile projects, with all their uncertainty.

This article has presented you with a selection of suitable contract models to use as a framework. You now understand the advantages and disadvantages of designating a product owner from either the contractor’s or client’s side. In addition, you have gained an overview of the various agile contract models.

• Now you understand the advantages of setting a fixed price or invoicing based on expenses incurred or other metrics.
• You have become familiar with several contractual agreements that are well-suited to agile projects, but have also learned about their limitations.
• You have also learned about other substantive factors to consider in your cooperation agreements when using the selected contract model.

The fundamental importance of the “good faith” principle is even greater with agile projects than with other projects. Reaching the shared goals demands that the contracting parties cooperate and not try to take advantage of each other.

The motto should always be a focus on the project’s success. If this is really done, then choosing the most suitable contract model is relegated to a mere necessary formality.

Do you have experience with agile contract models? What, in your opinion, requires particular attention? Please leave us a brief comment.

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management. Download the eBook now (just click, no form).

And sign up for our bi-weekly blog newsletter to make sure you receive all our updates.

About the author:Antje Lehmann-Benz, PMP, PMI-ACP, PSM expert is a trainer for project management with a particular focus on agile practices and Scrum seminars. Furthermore, she has experience as a software trainer (Jira, Confluence) and consultant. In addition to teaching frameworks and theory, she is experienced in the use of agile games and practical exercises to reinforce the knowledge gained.

Read more about Antje Lehmann-Benz on Linkedin.

Der Beitrag Agile Contract Models – Working with Cross-Corporate Teams erschien zuerst auf Blog Project Management for Companies.

Such agile retrospective meetings aid the continuous improvement of processes, methods, and teamwork.

This article covers the following topics:

• Agile retrospective: definition
• Who should participate in an agile retrospective?
• Organization of an agile retrospective
• Which retrospective methods are there?
• Retrospective examples for advanced practitioners
• Retrospective tools and templates for virtual teams
• What happens after the agile retrospective?
• Conclusion – Agile retrospective

Let us get started with the definition of agile retrospective!

Agile Retrospective: Definition

Retrospectives in project management are regular team meetings with the aim of continuous improvement based on past experience. In various “reviews”, team members evaluate together what went well and what did not. In addition, they analyze why things went well or did not meet expectations. Measures to improve processes, methods and teamwork are formulated and implemented.

The basic concept of a retrospective is anchored in the 12th principle of the agile manifesto:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Agile teams work in preferably short intervals called iterations (aka “Sprints” in Scrum). These can be viewed as development cycles, but they also represent learning cycles because it is assumed that complex endeavors require a step-by-step approach in which it is necessary to frequently pause to evaluate oneself and the (intermediate) results. “Inspect & adapt” rituals are therefore a key ingredient of each iteration.

This gives you the opportunity to significantly influence the further course of your project. Three factors are analyzed and, if necessary, adapted:

• Product
• Process
• People

The iteration review meetings or product review meetings with the stakeholders at the end of each iteration serve to evaluate and adapt the product. It also benefits the further development of its functionality, thanks to the stakeholder feedback.

What remains are the aspects of processes and teamwork – which the agile retrospective meetings, aka agile sprint retrospectives, are designed to address. Retrospectives are held at the end of an iteration, just like the review.

Thus, the agile retrospective differs from the Lessons Learned meetings used in traditional project management, especially with regard to the timing and frequency. With projects planned in the traditional manner, you generally have to sit down with the team once at the end of the project to discuss what happened and what has been learned. With agile teams, this happens on a regular basis after each iteration – before the next iteration begins. This enables you to immediately apply what you have learned to the current project, instead of merely gathering these findings to use on some future project.

Who Should Participate in an Agile Retrospective?

Stakeholders can be invited to attend a retrospective meeting, but their presence is normally not necessary. If the team wants to speak openly and honestly about the iteration that has just ended, having stakeholders present can be a hindrance.

Agile coaches (a “Scrum Master” in a Scrum Team) help the team identify good practices and possible improvements that can be used in the next iteration. An agile sprint retrospective is therefore a joint team event – and experienced coaches always have a sufficient repertoire of formats to support this effort.

Candor and honesty are therefore essential in a retrospective.

Although the team might be quite satisfied with its accomplishments, with the team members congratulating themselves on a job well done, it is also important to be open about any critical issues and discuss these. This includes any feelings and emotions.

Provide a safe space for dealing with these.

At a minimum, the following people should participate:

• A Product Owner (or also a functional project manager, depending on how the team is organized)
• All other team members
• A team coach

Organization of an Agile Retrospective?

An agile retrospective typically takes up to three hours, depending on the length of the iteration being reviewed.

Experience has shown that a meeting with five phases is most effective:

1. Provide an atmosphere conducive to discussions
   The team meets for the retrospective. The participants strive to avoid distractions and agree to participate in an open discussion in which each person is treated with respect.
2. Gather the issues to be discussed
   Together, the team members reflect on how the iteration went and brainstorm ideas for possible improvements.
3. Gain insights
   All the participants delve deeper into the issues that were discussed: what were the causes? What specific steps can be taken to improve things?
4. Reach decisions
   As per the agile principle that “less is more”, the group agrees on 1-2 specific improvement measures to be implemented in the next iteration.
5. Conclusion
   After reaching an agreement in phase 4, the retrospective is concluded, and the team members go their separate ways again. The next iteration can now begin.

What Retrospective Methods Are There?

Generally speaking, no special retrospective methods are necessary for holding an agile retrospective, with its individual phases, for your team. It is also not necessary to strictly follow each of the individual steps listed here, although the meeting generally quickly progresses from one step to another. The important thing is to end the meeting with an agreement on 1-2 specific improvements for the next iteration.

Experience has shown that the team often runs out of agile retrospective ideas and loses creativity after a few retrospectives. There is then an urge to abolish these retrospective meetings. Or the project team still has no idea how to ensure that the retrospective meetings are productive and creative.

For these situations, there is a wealth of retrospective methods and moderation techniques for engaging your team and making it easier and much more exciting for the team to work on improvement processes.

Our tip: A website with a trove of good agile retrospective ideas is Retromat: it provides formats for every phase of the retrospective. In the next section, we present a selection of these.

Please note: Teams generally enjoy trying these various techniques, but they can also be a bit overwhelming or exhausting. So, keep in mind that: less is more.

Experienced team coaches use 1-2 methods per agile retrospective. They repeat some methods occasionally to avoid asking too much of the team. They sometimes completely omit one or the other a few times in between.

Choose the methods best suited to your team’s level of development or experience. The “starfish” is a classic format that is easy to use and understand and even works remotely if you use an electronic whiteboard.

For a format such as “Writing The Unspeakable”, on the other hand, you need a team that can meet undisturbed in a separate room and has members that know and trust each other well.

Our tip: Gently introduce your team to the latest retrospective techniques. Choose a rather simple method. Over time, you can progress to more demanding techniques.

Do many of the issues discussed deal with the environment in which your team works? If so, it makes sense to involve the stakeholders as well at some point.

You might also enjoy reading our blog article on agile contract models.

1) Retrospective Method for Warm-Up (Icebreaker)

ESVP: Each team member is asked, in turn, which of these they feel like in today’s retrospective meeting:

• Explorer (eager and enthusiastic)
• Shopper (looks to see if any insights can be gained)
• Vacationer (enjoys the time off from other duties)
• Prisoner (would rather be somewhere else)

Each person writes the first letter of their choice on a piece of paper, and the papers are collected anonymously. If any of the papers show a V or a P, this is discussed. Why does someone feel like a “vacationer” or a “prisoner” in this meeting? What needs to change to improve the team’s attitude toward the retrospective?

2) Retrospective Method for Making a List of Issues

Sailboat / Motor yacht: Together, the retrospective participants view a picture of a boat on a flipchart or something similar and then, after writing the issues important to them on sticky notes, paste these sticky notes on the area of the picture they feel best represents their issue. Is the issue related to something that:

• Motivates us as a team (boat engine or sail)?
• Could present a future hazard (iceberg)?
• Is slowing the team down (anchor)?

Our download tip: Here is the template for holding a remote retrospective using the sailboat exercise. You can copy and use it for retrospectives with your team.

3) Retrospective Method for Gaining Insights

5 Whys: Originally developed by former Toyota CEO Taichii Ohno. Just as a child would do, we ask the question Why? five times. Let us look at an example.

Problem: We missed the delivery deadline for our new product version.

Why did we miss the deadline?

Because not everyone finished their tasks on time.

Why was not everyone finished on time?

Because there were a lot of urgent support requests to deal with at the same time.

Why were there numerous urgent support requests needing our attention?

Because an important hardware update that was planned at the same time led to some bugs.

Why was an important hardware update planned for the exact same time?

Because the priorities for the team were not clearly set and planned.

Why were the team’s priorities not clearly defined and scheduled?

Because the stakeholders disagreed which was more important.

What caused the problem? Conflicting priorities among the stakeholders; the priorities were not coordinated well.

Taiichi Ohno believed the source of the problem would be pretty clear after the fifth “Why?” question. After doing this exercise, you can discuss the result and brainstorm ideas for avoiding this problem in the future. For example, it might be helpful to escalate the problem to the next higher level or help stakeholders reach an agreement.

4) Retrospective Method for Reaching an Agreement:

Using colored dots to vote: Present the measures suggested in the retrospective phases and then ask participants to vote on these using the colored dots they have been given. Each person is given two or three colored dots to allocate as they see fit to indicate the measures they deem most important. They can give all their dots to a single measure or distribute them among several measures. The measure with the most dots is implemented in the next iteration.

5) Retrospective Method for Concluding the Meeting

Respect and appreciation: Each team member is asked to personally thank or praise another participant for something specific that that person contributed to the project. It can be for the help they gave or their strong commitment. After everyone has contributed, the retrospective can be concluded.

Retrospective Examples for Advanced Practitioners

Is your team a group of experienced professionals already very familiar with retrospectives? If so, here are a few retrospective examples of methods you may not have used before:

Retrospective Example 1: Futurespectives

In a futurespective, as the name suggests, you look ahead to the future instead of back to the past. This is especially useful at the project’s start when the goals and objectives are being defined and the risks are being identified. Possible formats that have proven successful are:

• Remember The Future – The team (possibly together with stakeholders and maybe a customer) is asked the agile retrospective question: “Assuming that the project just ended and was a complete success, what made it a success?”
• Pre-Mortem – Turning this agile retrospective question around to identify scenarios that you would want to avoid, ask the participants: “Assuming that the project just ended and was a complete failure, why exactly was it a failure? What caused the failure?”
• Hopes & Concerns – Everyone is given the chance to express their hopes and concerns regarding the project just starting, and these are then discussed with the other participants.

Another interesting read: Agile Project Management Certifications

It is also enlightening to repeat an exercise such as this at the project’s halfway point to see what has changed since the project began.

Retrospective Example 2: Liberating Structures

Liberating Structures was originally developed to act as a counterpoint to monotonous presentations ‒ “Death by PowerPoint” (too many slides with too much content) ‒ and endless meetings in which everyone just sits there waiting for them to end. It is a collection of formats designed to extract innovative ideas from the group by using the swarm intelligence of the group’s participants. This technique is useful in other areas as well, but it works especially well in retrospectives.

Tip for beginners: 1-2-4-all: A topic is presented (to encourage more fun and creativity, the question can be formulated in a negative way. For example: “What is the best way to hamper our company’s agility?”).

• The team has 1 minute in which each participant writes as many ideas as possible on a piece of paper.
• Next, each participant selects a partner in the room. For the next 2 minutes, each pair discusses their ideas and creates a new, consolidated list.
• Afterward, each pair gets together with another pair. Each group of two pairs now has 4 minutes to discuss the ideas on their lists and create a new, consolidated list.
• In the final step, each group of four has 5 minutes to discuss and select the one idea that they find most important or concise to present it to the entire group later. Each group can write the idea on large index cards or a flipchart and then explain their idea to the entire group. Although the assignment was framed as a negative question, the ideas generated can then be reformulated as positive ideas.

Retrospective Example 3: Agile Games

Agile games are not only helpful for teaching agile methods in introductory workshops, but the gamification principle has also shown that formats using games and / or competition are more effective than discussions or presentations. They lead to a better long-term understanding of what has been learned. Familiar simulations such as Ubongo Flow Game, Lego4Scrum, and the Fearless Journey awaken participants’ playful instincts and function as direct, and often tactile, learning experiences.

Tip for beginners: White Elephant Sizing:

• The group estimates the work using T-shirt sizes as a reference. This gives the participants a feel for estimating the relative scope in agile projects.
• In a retrospective, you could ask the participants to start by estimating the amount of work involved in ordinary home activities (such as vacuum cleaning, decluttering a closet, renovating a kitchen, or cooking a meal) and then discuss within the team how each person arrived at these estimates.
• The insights gained can be used in the next iteration when it is time to estimate the effort involved in fulfilling “real” requirements.

Retrospective Tools and Templates for Virtual Teams

Some of the formats discussed above are intended for groups meeting in-person in a room. Project teams are increasingly global though and collaborating remotely. However, that does not preclude the use of innovative retrospective formats.

In the agile retrospective, it helps to not only have a good videoconferencing tool (ideally with the webcams turned on so that everyone can see each other), but also the following tools:

1. The website “Fun Retrospectives” has developed its own remote tool for the Starfish format.
2. Interactive virtual whiteboards, such as IdeaBoardz, Miro, Mural, and Padlet, offer some templates for retrospectives. Team members can add their input to these boards in real time.
3. If you provide everyone involved with a set of Google slides or a Word file, you can use these together with the team members simultaneously and in real time. Tables, sticky notes, etc. can also be used.
4. For companies whose security policies prevent the use of the options mentioned above, you can simply create a presentation and share it directly from your screen. You can then add the team members’ feedback directly to this presentation so that everyone sees it right away. Another option is to email the presentation to the participants beforehand, which allows everyone to reflect on it and jot down agile retrospective ideas before the meeting. The combined feedback can then be further discussed in the meeting.

Note: A possible retrospective template for items 3 and 4 is the sailboat graphic in the figure above (find the download of the sailboat graphic here).

The Miro software shown below provides another retrospective template.

What Happens After the Agile Retrospective?

Ideally, your team comes up with at least one concrete, immediately implementable idea in the retrospective. It is important that the team actually implements this measure and that their efforts are taken seriously by those around them so that the team feels that the retrospective was worthwhile and productive.

You should therefore document improvement measures in the backlog.

Treat these with the same diligence as a functional or technical requirement in the next planning meeting: as something that must be planned and accomplished.

Metrics you can use to track the success of the implementation are:

• Continuous measurement of the productivity and number of tasks being handled simultaneously (team velocity)
• Reaching the target number of product users (customer surveys)
• Team satisfaction
• Team’s confidence in the quality of their product (employee surveys)

Conclusion – Agile Retrospective

In this article, you have read about:

• Why you should not wait until the project is over to hold a Lessons Learned meeting, and how holding agile retrospective meetings regularly can contribute to possible process improvements.
• Ways to ensure that your retrospectives are creative and productive in the long-term, including retrospective methods well-suited to remote and / or experienced teams.
• How to identify specific measures for improvement, implement these, and track their success.
• The role of agile coaches and Scrum Masters in assisting teams.

Make the effort to tackle this topic and contribute to greater project success with regular agile retrospectives!

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management. Download the eBook now (just click, no form).

And sign up for our bi-weekly blog newsletter to make sure you receive all our updates.

What has been your experience with the retrospective in agile project management and possibly with specialized methods? We look forward to hearing from you!

Author: Antje Lehmann-Benz (PMP, PMI-ACP, PSM expert / instructor in Agile Methodology)

Antje Lehmann-Benz, PMP, is a project management instructor with a special focus on agile issues and scrum seminars. She also has experience in providing software training (JIRA and Confluence) and consulting. In addition to instructing on frameworks and theory, she is also experienced in the use of agile games and practical exercises to reinforce the knowledge gained.

Read more about Antje Lehmann-Benz on LinkedIn.

Der Beitrag Agile Retrospective – Methods and Examples for Projects (with Downloads) erschien zuerst auf Blog Project Management for Companies.

In the future, working on projects will require a clearer focus on the business value, innovative strength and creativity as well as shorter, yet still solid planning horizons. Companies are implementing this change which is evident from the emergence of, and request for, new agile job descriptions. Agile project management certificates play a role in this context.

What you will find out in this article:

• New job descriptions emerging through agile project management
• Why Scrum certifications make sense
• Further approaches and certificates for agile project management
• Overview of key agile certifications
  • PMI Agile Certified Practitioner (PMI-ACP)
  • Certified Scrum Master (CSM)
  • Professional Scrum Master I (PSM I)
  • Certified Scrum Practitioner (CSP)
  • Scaled Agile Framework (SAFe)
• Which agile PM certification is right for you?
• Conclusion – Agile PM certifications

Let us get started!

Agile is not your thing? Read about traditional project management certifications.

New Job Descriptions through Agile Project Management

Did you know that Scrum Master and increasingly Product Owner are turning into fully-fledged job titles?

Originating in the name of a role in the Scrum team, these terms are explicitly used in job advertisements more and more often. Moreover, companies are including these terms in the career path for employees.

Subscribe to the TPG Blog Newsletter now and never miss another blog post.

As in every field, the candidate’s experience is key. It must not be underestimated. Beyond professional experience, Scrum Masters require the below skills in their highly mediatory and supportive role:

• Knowledge of human nature
• Tact
• Ability to moderate
• Conflict resolution skills

Why Scrum Certifications Make Sense

In and around Scrum, there are countless misunderstandings. The successful introduction of the methods is also hugely dependent on the participants’ stock of knowledge.

This is why the basics of agile project management certifications, such as the Professional Scrum Master I by Scrum.org or the Scrum Alliance’s Certified Scrum Master, can be very helpful.

These two certifications are meant for those starting out in agile methods. Certificate holders indicate that they have understood the fundamental principles of the Scrum Framework and have demonstrated this in an exam.

By means of one of the above certifications, they furthermore show their readiness to:

• lead and support others in such a role.
• help the organization implement Scrum.
• gain more experience with Scrum.

The last point is particularly relevant if you are still at the beginning of your Scrum career.

Your agile project management certifications will demonstrate that, as a Scrum-Master-to-be or an active Scrum Master:

1. You are familiar with the relevant contents of the Scrum Guide and further literature.
2. You have demonstrated this knowledge in an exam situation.

Further Approaches and Certificates for Agile Project Management

Excellent Scrum Masters do not limit themselves to Scrum alone. There is a variety of agile methods and approaches. They can be combined and have many aspects in common. For example, many methods are based on the following:

• A trusting and open concept of man
• An iterative-incremental method of operation

If in doubt whether a project needs an agile, traditional or hybrid approach, read this article.

Moreover, there are environment issues in organizations to which agile methods often pay little attention. For instance, we could name the following here:

• Portfolio management
• Resource management
• Project selection methods
• Organizational structuring
• etc.

All this takes us back from product development at individual team level for which Scrum was primarily developed to project management issues. This requires a more holistic and higher-level perspective on things.

This is where the PMI-ACP® (“Project Management Institute Agile Certified Practitioner”) comes in.

PMI Agile Certified Practitioner (PMI-ACP)

The PMI-ACP certificate is meant for people who already look back on (agile) project experience. It claims to gather the ideas of all agile methods and consolidate them in a standardized way.

The Project Management Institute (PMI)® is actually very serious concerning this goal: after all, its standard manual for the project management industry, the “Guide to the Project Management Body of Knowledge” (PMBOK® Guide) in the 6th edition was published in a bundle together with the new Agile Practice Guide in 2017. The PMBOK® Guide is now in its 7^th edition – but the Agile Practice Guide is still up to date.

Learn about PMBOK Guide Seventh Edition and its implications for the PMP® exam.

Agile Practice Guide

Apart from the consideration of individual agile methods, the Agile Practice Guide also contains guidelines and assistance for situational method selection. In addition, it bridges the gap between agile and traditional project management methods.

These are still very much needed in all the situations in which agile approaches are not sufficient to tackle problems.

The contents of the Agile Practice Guide are the result of the collaboration of the PMI with the Agile Alliance (an association of many promoters of agile ideas, not to be confused with the Scrum Alliance).

This indicates a solid expert base for the new Agile Practice Guide.

Since March 2018, this guide has also been the official exam reference for the PMI-ACP – but only as one of many relevant sources from the catalogue of agile literature.

As of late, the popularity of the Agile Certified Practitioner certificate has risen sharply. Hence, there is a demand for high quality material to prepare for the exam.

At least, the Agile Practice Guide helps exam candidates pin down the perspective of the PMI on agile project management. It also gives practical examples of how to use the methods presented.

Combination of PMI-ACP with the PMP Certification

By the way, the PMI-ACP certificate and the traditional PMP® (Project Management Professional) of the PMI are an excellent combination of certificates.

Interested in hybrid project management? Learn how to combine agile and traditional methods in this article.

Another point in favor of the combination is that the examination requirements are easier to meet for candidates with a PMP® certificate. You will not have to prove additional project experience if you are PMP. However, the same does not apply to agile project experience and training. Proof of this will be requested from all candidates.

Since January 2021, the PMP® exam has included additional questions on the following three project management approaches:

• Predictive
• Adaptive / Agile
• Hybrid

This means that even prospective PMPs must be familiar with a few agile ideas and methods now, e.g. Backlog maintenance, estimation methods or Retrospectives.

Overview of Agile Project Management Certifications

Below, you will find a comparison of the agile project management certifications mentioned in this article. In addition, we have included information on the certifications Certified Scrum Practitioner (CSP) for advanced agile project managers and Scaled Agile Framework (SAFe) for agile scaling.

The PMI Agile Certified Practitioner (PMI-ACP)
Certificate awarded by: Project Management Institute

Prerequisites

– 2000 hours of project experience (does not apply to holders of a PMP certificate)
– 1500 hours of experience in agile environments
– 21 contact hours of training in agile practices (e.g. by completing the PMI-ACP training at TPG)

Type of Exam

On-site at the test center, 120 multiple-choice questions with four answer options and only one correct answer, to be answered in 3 hours

Alternative: Online proctored exam (online exam with webcam monitoring by an offsite proctor)

Passing Score (share of required correct answers)

Secret (estimated at approx. 70%)

Exam Fee

$435 (PMI® members, a little higher for non-members)

Validity

3-year cycle (30 Professional Development Units – PDUs must be earned over this period in agile environments and / or topics)

Purpose

Standardization of as many agile practices as possible

Target group

People looking to prove and improve their experience with agile methods and their understanding thereof

Certified Scrum Master (CSM)
Certificate awarded by: Scrum Alliance

Prerequisites

Completion of a 2-day training by a specially authorized trainer, no more than 90 days before taking the exam

Type of Exam

Online; 35 multiple-choice questions, to be answered in 1 hour

Passing Score (share of required correct answers)

68,6%

Exam Fee

Exam can only be taken after booking a training and is covered by the training fee

Validity

2-year cycle (thereafter re-certification online for $100)

Purpose

Clarification and promotion of Scrum

Target group

People wishing to take a first step towards mastering Scrum

Professional Scrum Master I (PSM I)
Certificate awarded by: Scrum.org

Prerequisites

No formal prerequisites (deep understanding of the Scrum Guide is necessary to pass the exam; practice exam “Scrum Open” is available at scrum.org)

Type of Exam

Online: 80 multiple-choice questions with a range of different answer options and one or more correct answers, to be answered in 1 hour

Tip: At TPG, we offer a Scrum company seminar with the option of taking the exam directly after. After only three days, participants will be able to hold their PSM I certificate in their hands.

Passing Score (share of required correct answers)

85%

Exam Fee

$150

Validity

Unlimited

Purpose

Clarification and promotion of Scrum

Target group

People wishing to take a first step towards mastering Scrum

Certified Scrum Practitioner
Certificate awarded by: Scrum Alliance

Prerequisites

– Certificate as an A-CSM (Advanced Certified ScrumMaster), minimum of 2 years of experience in the role of Scrum Master within the last 5 years
– Completion of the homework assigned at the end of the course within 12 months

Participation in the course is also possible without meeting these prerequisites. However, in this case no certificate will be acquired.

Type of Exam

–

Passing Score (share of required correct answers)

–

Exam Fee

$250

Validity

Permanent

Purpose

Expanding the agile product management expertise

Target group

The CSP-SM certification is suitable for Scrum Masters whereas the CSP-PO certification is suitable for Product Owners.

Scaled Agile Framework (SAFe)
Certificate awarded by: Scaled Agile, Inc.

Prerequisites

– 5+ years in software development, testing, business analysis, product or project management & experience with Scrum
– Course covering the SAFe content with a training provider

Type of Exam

45 multiple-choice questions in 90 minutes, possible online

Passing Score (share of required correct answers)

76%, 34 answers

Exam Fee

$435

Validity

1 year after the validity expires the certification can be renewed for a fee of $100 without taking another exam.

Purpose

Agile scaling / Scrum methods

Target group

Senior staff, Scrum Masters, Product Owners, managers of requirements, releases and testing, coaches, project managers who wish to organize multiple teams successfully using agile methods

Which Agile PM Certification is Right for You?

You are familiar with the most important agile project management certifications now. Yet, how do you know which one is right for you? Initially, it makes sense to begin with the basics of Scrum – thus, you create a good basis for the majority of the above certifications. Afterwards, you have the option to expand your knowledge as shown in the following figure:

Conclusion – Comparison of Agile Project Management Certifications

This article has introduced you to agile project management certifications. You have also found out where the application of agile methods can make sense. Particular emphasis was placed on Scrum.

You have become familiar with the following agile certifications:

• PMI Agile Certified Practitioner (PMI-ACP)
• Certified Scrum Master (CSM)
• Professional Scrum Master I (PSM I)
• Certified Scrum Practitioner (CSP)
• Scaled Agile Framework (SAFe)

This will make it easier for you to judge which path would be most advisable for you and your employees.

Our final tips

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management. Download the eBook now (just click, no form).

And sign up for our bi-weekly blog newsletter to make sure you receive all our updates.

Are there important agile project management certifications or aspects that we have missed? Did you find the tips helpful? We look forward to receiving your comment below.

About the author:Antje Lehmann-Benz, PMP, PMI-ACP, PSM expert is a trainer for project management with a particular focus on agile practices and Scrum seminars. Furthermore, she has experience as a software trainer (JIRA, Confluence) and consultant. In addition to teaching frameworks and theory, she is experienced in the use of agile games and practical exercises to reinforce the knowledge gained.

Read more about Antje Lehmann-Benz on Linkedin.

Der Beitrag Agile Project Management Certifications: A Comparison – How to Proceed erschien zuerst auf Blog Project Management for Companies.

Learn how to best conduct stakeholder analysis and stakeholder management in the project environment in a target-oriented manner using a few tools and methods. Find an overview of the topics of this article below:

• What is stakeholder management?
• What are stakeholders in a project?
• What is stakeholder analysis vs. stakeholder management?
• Stakeholder analysis definition
• How to conduct stakeholder analysis (tools and methods)
• How to draw up your stakeholder list
• Proper interaction with stakeholders
• Stakeholder management examples
• How to manage stakeholders in agile projects
• Conclusion

To begin with, let us define the term “stakeholder management”.

What Is Stakeholder Management?

The goal of stakeholder management is to adequately involve project participants and those affected by the project and to clarify expectations. This is worthwhile, as satisfied stakeholders increase the chances of project success more than virtually any other factor. There are good tools and effective recommendations for action for effective stakeholder management.

What Are Stakeholders in a Project?

The origin of the word goes back to old gold digger times: if someone wanted to make their claim to an area visible, they drove four stakes into the earth around it.

In project management, the individuals who stake claims in connection with a project or its results have come to be called stakeholders. These days, the term “stakeholder” is used not only in English but also in other language regions.

Please note, however: Different project management organizations have quite different definitions of the term. Hence, it is often understood somewhat differently by different people. Find a short overview of the most important organizations below:

Definition of Stakeholder according to the PMI®

In the Guide to the Project Management Body of Knowledge (PMBOK® Guide) by the Project Management Institute (PMI®), the deifinition is as follows:

Stakeholders can be “individuals, groups, or organizations that may affect, be affected by, or perceive themselves to be affected by a decision, activity, or outcome of a portfolio, program, or project.”
(PMBOK® Guide 7, p. 31)

Definition of Stakeholder according to the IPMA

The International Project Management Association (IPMA) writes something similar in their current guide Individual Competence Baseline (ICB 4):

Stakeholders are “all individuals, groups or organizations who are involved in, influencing, affected by, or interested in, the execution or the outcome of a project.”

Important note:  According to both definitions, it is possible for both project team members and project managers to be stakeholders themselves.

Definition of Stakeholder according to the Scrum Guide

This is different in the Scrum Guide by Scrum founders Jeff Sutherland and Ken Schwaber. Here, the definition is:

Stakeholders are individuals “with an interest in the project outside the Scrum Team.”

It is open to question whether this subtle difference has the effect that, when following PMI and IPMA standards, the team will distinguish less between “us” and “them”.

Subscribe to the TPG Blog Newsletter now and never miss another blog post.

What are Typical Stakeholders?

So, who can be a project stakeholder?

Examples of stakeholders and key stakeholders (= important stakeholders who have direct influence) are:

• Project sponsor
• Corporate management and managers
• Project Management Office (PMO)
• Customers
• Users of the product created in the context of the project

Additional ones may be:

• For construction projects: local residents, politicians, etc.
• Regulatory bodies whose requirements must be met, etc.

Important note: There can be hidden stakeholders who are not known straight away. Likewise, if new projects are taken on and a project manager is not yet entirely familiar with a company, the stakeholders will have to be identified first.

Claims of Stakeholders

The “stakes” that stakeholders can have in a project range across very different dimensions, such as:

• General interest in the project
• Desired properties in the project outcome
• Rights in areas in and around a project
• Knowledge and insights that should be included
• Power to impact the project in some way
• Investment in organizations and outcome
• And many more

What is Stakeholder Analysis vs. Stakeholder Management?

First, the below figure is intended to illustrate how the terms stakeholder management, stakeholder identification and stakeholder analysis relate to each other as conceived in this article:

Hence, in this article, we see stakeholder management as a subdiscipline or a knowledge domain of project management.

Let us move on to stakeholder analysis.

Stakeholder Analysis Definition

The stakeholder analysis asks who the stakeholders in the project are (stakeholder identification). It proceeds to identify their characteristics, such as influence, claims and level of interest in the project. Thus, the stakeholder analysis is a subdomain of stakeholder management.

When conducting a stakeholder analysis, you additionally document the following:

• Needs
• Requirements
• Wants
• Expectations
• Fears

This document will help you derive the project requirements. That is what makes the stakeholder analysis so central. If it does not take place, or is not completed, important project requirements may be overlooked.

In such a case, you may find stakeholders you never knew existed speak up during project execution – typically not a pleasant situation.

Things can get really unpleasant if stakeholders feel ignored.

Tools and Methods for Stakeholder Analysis

If you limit the consideration of who the stakeholders in your project are to yourself and your team, the danger of forgetting somebody will be high.

To avoid overlooking any stakeholders, you had best approach it as follows:

Conduct a brainstorming session with people who are well-versed in the matter and / or in the project environment. If you plan it right, you can achieve good results with such a workshop.

How to Brainstorm for Stakeholder Analysis

Good brainstorming follows these 12 rules:

1. There is a moderator but no leader
2. Set a time limit and make sure that there are no interruptions during the workshop
3. The topic of the session should unleash creativity and not restrain it
4. Criticism and judgement of the ideas is not desired
5. Neither are irritated noises, grimaces or laughter
6. Ideas are not discussed
7. The quantity of ideas counts (reverse the thought of ‘quality over quantity’)
8. Radical and strange ideas are welcome
9. Each idea is taken down
10. The notes remain unstructured
11. The participants of the session should build on each other’s ideas
12. A selection only takes place after brainstorming

If you invite the right people and manage to stick to these rules, you should end up with a comprehensive collection of stakeholders and their most important characteristics.

Our tip: Are there introverted people on your team or among the experts you are consulting? Are there some people who dominate the discussion and intimidate others? If so, use a technique for brainstorming that ensures that all voices are heard. The Nominal Group Technique which we describe in our article on Risk Management in Project Management.

If you follow the 12 rules for good brainstorming, you will be able to gather a multitude of important and unstructured contributions regarding the stakeholders in your project.

Now you have an unsorted collection of names and important points on your project stakeholders. What could you do to get this list into a structured and presentable format?

It makes sense to use an affinity diagram.

The kick-off workshop also benefits stakeholders and overall project success.

Affinity Diagram for Stakeholder Classification

Create your affinity diagram in three steps:

• Brainstorming (this you have already done)
• Find and name suitable groups
• Assign your stakeholders to the groups

An evaluative assignment can of course have a certain political significance. You should consider carefully how you present such a diagram and, above all, to whom. When used within a project team, it can serve to clarify strategies against resistance.

Clear communication rules help in case of doubt.

Matrix for Assigning Responsibilities

Clear communication rules will facilitate awareness in your team. For the collaboration in the project, they will become familiar with the diverse stakeholders’:

• Contact person
• Claims
• Requirements

For this purpose, you can draw up an overview outlining who is responsible for what; and when they should be informed about what.

The below matrix for assigning responsibilities is a good example of this.

A Responsibility Assignment Matrix (RAM), aka RACI Matrix, shows which stakeholder is authorized or responsible for what. In addition, it outlines whom to consult or inform on what topic. The following graphic presents an RAM / RACI matrix.

No matter whether you follow agile, traditional or hybrid methods in your project – fundamentally, you will wish to promote open and transparent collaboration with your stakeholders and build a relationship of trust, if possible.

Our tip: Use different proven methods of visualization to create a clear communication structure. This ensures that the right people will be informed about things they need to know; thus, it fosters the smooth collaboration within your project.

How to Draw Up Your Stakeholder List

One thing that will help with stakeholder management in any case is a detailed list of all stakeholders. It should contain all important information, such as:

• Position at the company
• Role of the stakeholder in the project
• Needs
• Wants
• Expectations
• Project requirements
• Priority
• Issues
• Project tasks (with named assignment)

Find an example of one such list below.

So far, you have identified many stakeholders for your project and defined them in detail. Now you ask yourself the following question: what really matters when dealing with them?

Proper Interaction with Stakeholders

This is where your soft skills come in. Hardly any other task in project management (apart from team management) places as great demands on interpersonal skills as the right interaction with the stakeholders.

You should be able to:

• Understand the attitude and personality of the stakeholders
• Respect confidentiality
• Maintain your integrity
• Network actively
• Set the right tone
• Lead others without appearing to be bossy

If you can do all this, you are in a good position to manage the expectations of your stakeholders.

Please note: It is not your task is not to “manage” the stakeholders as individuals. You have to actively take care of your stakeholders’ commitment to the project and their expectations.

Stakeholder Management Examples

No project in the world will manage to fulfill all expectations. You may know this, for example in cases where a team that is already very busy is confronted with ever-new change requests. A no or an alternative offer to stakeholders can be unavoidable at times for that reason only.

Please note: It is never possible to fulfil all wishes. This means you have to be able to say no at times or consider alternatives.

However, to be able to decide this effectively, your initial job is to listen attentively and to understand. When consulting your stakeholders, you should know which questions you are going to ask and to whom you are asking them.

This is aggravated by the fact that stakeholders are often unable to express their expectations in a comprehensible way. Sometimes, they do not even know themselves what they want exactly. In such a case, you need to make suggestions that might help them along.

What is more, expectations are often influenced by people who are outside your sphere of influence. Here are two possible scenarios:

• If a head of department constantly expects new functions in your software, the reason for this may be pressure from the next higher management level.
• Is there a stakeholder whose wishes are completely opposed to those of another? In this case, the difficult task is to make well-balanced decisions and to communicate them actively.

The agile project management environment provides an interesting method for visualizing different stakeholder groups.

Make Use of Personas

Personas are profiles of typical members of user groups. They do not have to correspond to real existing individuals; they should merely represent them. This allows the team to better identify the stakeholders and engage with them.

This technique is popular among software development teams. As a result, the team members are less likely to lose sight of the people for whom they are ultimately doing their work.

What is exciting: just by creating the personas, you can unleash creative processes and generate ideas for new solutions.

Our tip: Use the persona approach for better visualization. Every now and then, a team should check whether the personas are still up to date and revise them if necessary.

Force Field Analysis

Some projects are faced with the challenge of bringing about major changes. Not all stakeholders will be welcoming these.

If this is what you encounter, your project team might find it difficult to continue working effectively against high levels of resistance.

There is rarely a simple solution to such situations.

This is where methods such as active change management or even acceptance management are necessary. Of course, it is always important to understand the reservations – usually, they are there for a reason.

With the force field analysis, Kurt Lewin (1890-1947) developed a visual depiction juxtapoising driving and restraining forces. This makes it possible to evaluate the probability of a successful change.

In this context, driving forces represent the initiation or support of a change. Examples of this could be:

• Order from a superior
• Advantages and incentives
• Competitive pressure
• Stakeholders actively advocating the change

Restraining forces, on the other hand, is the term for resistance slowing down or preventing a change. They can manifest themselves as:

• Apathy or aggression in people who are against it
• Technical problems
• Difficulties in communication
• Stakeholders who want to prevent change

The force field analysis assigns values to these attitudes on a spectrum in both directions and then calculates the average. The following figure shows an example of this.

How to Manage Stakeholders in Agile Projects

In the agile world, active stakeholder involvement is firmly established and even more important for project success than in traditional and more forward-planning project management.

Agile projects tend to have a high level of uncertainty which is why they need the following:

• Mutual trust and cooperation
• A common project vision and goals
• Room for stakeholders to contribute and show initiative
• Transparency and openness as key values
• Frequent interaction with stakeholders

For the last item in the list, most agile methods and frameworks have concrete specifications.

Scrum provides for a review of the deliverable intermediate results after each work interval (Sprint), together with the stakeholders. During this meeting, the latter can and must actively contribute their feedback. Thus, they help decide on the further course of the project.

In Extreme Programming, there is the principle of the customer on site. In this scenario, the customer or a representative and the team permanently work on the results together on site – or at least the customer has a say in them.

Not least because the Agile Manifesto requires “customer collaboration over contract negotiation”. This is a confident demonstration of the credo that even issues that are important in principle, such as contract negotiation, should never stand in the way of successful collaboration with stakeholders in the project.

Suggested reading: Agile, traditional or hybrid? When to use which method.

Conclusion – Stakeholder Management and Analysis in Projects

This article has introduced you to the meaning of the terms stakeholder, stakeholder analysis and stakeholder management and their relation to each other.

• Now, you know why active stakeholder management regarding their expectations and needs is so important.
• You have learnt about different methods of stakeholder analysis and the collaboration with the stakeholders.
• Plus, you have found out about the special meaning of close collaboration with your stakeholders in agile projects.

You now have a number of methods and tools at your disposal. They will allow you to better engage stakeholders in your projects and to balance their wishes with the project goals.

This will improve communication and thus the success of your future projects.

Our final tips:

Get to know the individually adaptable “PPM Paradise” – the optimal environment for your enterprise-wide project, program, portfolio and resource management (PPM). Download the free eBook “The PPM Paradise” now (just click, no form).

And sign up for our bi-weekly blog newsletter with information on more practical articles, eBooks, etc. to improve your project management maturity level.

What has been your experience in this field? Do you feel we missed an important point, and is there anything you would like to add to this article? Write a short comment now.

About the author:Antje Lehmann-Benz, PMP, PMI-ACP, PSM expert is a trainer for project management with a particular focus on agile practices and Scrum seminars. Furthermore, she has experience as a software trainer (JIRA, Confluence) and consultant. In addition to teaching frameworks and theory, she is experienced in the use of agile games and practical exercises to reinforce the knowledge gained.

Read more about Antje Lehmann-Benz on Linkedin.

Der Beitrag How to Conduct Stakeholder Analysis in Project Management and Stakeholder Management (Methods and Examples) erschien zuerst auf Blog Project Management for Companies.