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.

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.

Note that the article also includes the Comparing Project Management Methodologies PDF for download.

We will address each of the following topics:

• When to use traditional project management methodologies
• When to use agile project management methodologies
• Comparing project management methodologies: Traditional – agile
• When to use hybrid project management methodologies
• Software solution for hybrid project management: MS Project + Jira integration
• Conclusion – Comparing project management methodologies

Let us start.

When to Use Traditional Project Management Methodologies

A glance at the history of project management shows how and why traditional planning methods evolved as they did. Tools such as:

• Gantt charts to depict time intervals (developed in 1910)
• PERT & CPM for depicting interdependencies (developed in 1958)

as well as organizations such as:

• PMI and IPMA (founded in the 1960s)
• Axelos / Prince2 (founded in 1996)

were established in an era of large-scale projects of a longer duration. So, the project’s goals until completion were ‒ in theory at least ‒ clearly and carefully defined, and any change was costly. This meant that changes were considered to be disruptions. Everyone focused 100% on the goals.

Traditional project management methodologies, therefore, offered numerous methods for control and management. Even today, these methods are good for industries such as construction, plant engineering, pharmaceuticals, and some others.

Our tip: If you are planning a project in which the requirements are pretty clear right from the start and the work can be thoroughly planned, then the traditional project management methodologies are quite suitable. Likewise in environments with a high degree of statutory provisions or regulatory requirements, the traditional project management methods are likely to prevail.

When to Use Agile Project Management Methodologies

Agile project management with its methods is newer and originates in software development (greatly inspired by the concept of lean manufacturing). Agile project management methods have the following characteristics:

• They are well-suited for projects with a shorter duration
• There is a greater focus on the customer benefit than an overly rigid adherence to the goals
• They encourage flexibility in reaching the goals
• Changes are therefore welcomed if they provide useful improvements
• They are easy to use and have fewer guidelines than many traditional methods
• They rely on teams to self-organize themselves, which demands great trust

The latter is also clearly stated in the Agile Manifesto of 2001 with the following principles:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The agile principles listed in the manifesto all focus on the importance of interaction. Their objective is to move away from rigid processes and bureaucracy.

Scrum: The Most Widely Used Agile Method

Scrum uses a Product Backlog along with user stories instead of detailed product specifications. These user stories describe describe requirements from the user’s perspective. Also, the product backlog is incrementally enhanced during the development process, making it a “living” artifact.

The work to be done during a sprint is planned together with the stakeholders at the beginning of that particular Sprint. After that, the development team meets in a Daily Scrum to plan the work that needs to be done.

When a sprint ends, there is a review:

• The work results are presented to the stakeholders in a sprint review.
• After the review, the team organizes and holds an internal sprint retrospective. This is part of their self-management.
• In the retrospective, the team evaluates its methods and processes, as well as how well the team itself functioned as an entity. If improvements are necessary, then actions to be taken in subsequent iterations are discussed and decided upon.

In addition to this pure form of Scrum, there are also variations such as Reliable Scrum (with critical chain elements), and other agile tools. These include: Kanban boards in which there are no roles because these only serve to help visualize the work processes.

Our tip: Are the requirements in your project not really clear at the start and the goals somewhat flexible, and are short planning horizons an option? If so, agile project management methodologies could be suitable. Scrum, especially, could be the right choice if you want to achieve the objectives rather quickly and flexibly. Having a Scrum Master can help you with the process of implementing rules and establishing a fixed sprint cadence for you and your stakeholders.

Comparing Project Management Methodologies: Traditional – Agile

Traditional

In the traditional project management methodologies, the concept and the specification derived from it, provide the basis for the implementation. In the end, what counts is the acceptance and use of the overall result produced. The goals are largely stable over the course of the project whereas deadlines and costs are flexible.

 In traditional project management, there are roles such as:

• Project sponsor
  • Requests the project
  • Steering committee member
  • Makes decisions as necessary
• Project manager
  • Deals with the stakeholders
  • Plans and manages
  • Reports and communicates
• Team member
  • Responsible for completing work packages
  • Develops the deliverables
  • Time completion confirmation

Each of these has clear responsibilities.

Good communication is imperative when the people in these roles interact. In traditional environments, this communication is often in the form of status reports. The following kinds of meetings may be held:

• Kickoff at the start
• Planning meetings and status meetings during the project’s lifecycle, concluding with a Lessons Learned meeting at the end.

Agile via Scrum

Agile project management, on the other hand, focuses on the product version. Deadlines and costs are stable, but the goal is flexible (see figure above).

A customer can see and evaluate one of the initial versions of a product and give their feedback. You can then use this feedback to modify the original plan and, through regular contact with the customer, develop the subsequent versions.

This means that: The closer you collaborate with the customer, the better and more usable the result of your efforts will be.

In the end, the risk of unpleasant surprises is significantly lower than for methods involving long-term pre-planning. Each iteration of the product comes one step closer to meeting the customer’s needs, thereby enhancing the benefit to the customer.

Our tip: Begin by talking to your stakeholders and explaining to them that agile project management methods demand closer cooperation with the customer to work well. Ensure that you and your team understand that these methods demand an openness to new ways of working. Explain that it is completely normal that implementing these processes takes a bit of time and that the maturity level of Scrum teams only increases with experience.

When trying to decide between project management methods, ask yourself this question: can I afford to have flexible goals?

Of course, a product must also be able to be divided into individual usable components. This is more difficult in a construction project than in software development because in construction the individual parts are useless without the overall result.

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

In Scrum, there are three key roles:

• Product Owner
  • Single source of requirements
  • Manages and prioritizes the backlog
  • Communicates with the stakeholders
• Scrum Master
  • Leads the Scrum process
  • Ensures that the team is prepared for the process
  • Removes impediments
• Team
  • Evaluates the backlog items
  • Allocates tasks among the team members
  • Reports when DONE
  • Gives feedback in reviews and retrospectives

The Product Owner is the person responsible for the product requirements and the one who represents the stakeholder.

Scrum Masters ensure that the Scrum process is implemented. They support the team and remove any obstacles.

Note: Scrum Masters can also obtain certification to help them more fully comprehend the theory and support their work. A Scrum Master certification is viewed as the first building block of Scrum training. It can also be useful for other Scrum team members.

Reading tip: Agile project management certifications – A comparison

As the third role in Scrum, the development team bears much responsibility, as it:

• Estimates the required effort
• Chooses its tasks based on these estimates
• Informs others when these tasks have been accomplished (as per the agreed Definition of Done)

Important feedback in reviews and retrospectives comes not just from the stakeholders but also from the team itself in agile project management environments.

The roles are clearly defined when using Scrum methods. However, Scrum handles project responsibility differently (compared to traditional project management methodologies).

Our tip: Read the Scrum Guide to learn more about the roles before employees take on these roles. Your team members can, of course, retain their existing job titles while acting in a different Scrum role.

Communication: The meetings described in the Scrum Guide revolve around the idea that you should reduce the number of meetings to the absolute minimum necessary. These meetings are intended to cover most of the topics necessary:

• Daily
• Planning
• Review
• Retrospective

If stakeholders insist on receiving formal reports, you can – at least theoretically – alert them to the Scrum Boards and other sources of information or invite them to attend a review meeting. The Sprint Backlog clearly indicates what the team members are currently working on. Reviews can also include product demonstrations to increase transparency.

This article provides more detail on hybrid project management.

Resource Management in an Agile Environment

Regardless of the methods used, it is essential for the company to have a well-planned concept for resource management for project portfolios. This requires a centralized database which, due to its complexity, can only be coordinated by a Project Management Office (PMO).

Agile methods use fixed product / project teams. This greatly simplifies resource management.

However, this is insufficient at the project management level. Regardless of whether you are using agile or traditional project management methods, you will need to determine the actual availability, absences, and operations.

Further reading: Reducing resource conflicts with agile resource planning

Because resources are assigned to individual tasks in traditional projects, the differing deadlines make it difficult for people to switch from one project to another. In some situations, this can have a negative impact on productivity (see the first graphic below).

It is much easier for an employee to switch from one project to another if the team membership remains constant for at least the duration of one sprint. It is a good idea to align the sprint lengths and cadence among several projects. That way, resources can be shifted at the end of a sprint (see the second graphic below).

Our tip: Try to maintain the same cadence in all your projects so that team members can transfer from one project to another smoothly if need be.

Key Success Factors for Agile Project Management (a Selection)

 When considering agile project management methods, keep in mind these important points:

• Your company’s PMO needs expertise in the methods: it should be able to distinguish between traditional and agile methods and be able to choose the right processes based on the situation.
• Your company needs a system that overall best suits your requirements. Your stakeholders should commit to using the chosen processes.
• Reliable planning – even with agile methods – requires that you include the estimated tasks in a Sprint. Your Product Owner should prioritize the tasks beforehand correspondingly.
• The autonomous manner in which agile teams operate can also lead to surprises. You should be aware of this and be able to take action to mitigate the effects if necessary.
• The first step in implementing agile project management is to establish a uniform cadence in your timing. You can begin using the agile methods in a second step.

When to Use Hybrid Project Management Methodologies

Hybrid project management is basically a combination of the project management methodologies described above. Various combinations are possible, and here are just four examples of hybrid models:

1. The design and specification are agile, but the implementation is traditional.
2. The design and specification are traditional, and the hardware implementation is traditional, but the software implementation is agile. (Here it is important to keep in mind the interdependencies.)
3. The design, specification, and implementation of the hardware and software are traditional, the integration is agile.
4. The design, specification, implementation and acceptance test are traditional but occur in planned periodic iterations. This is therefore not a combination of traditional and agile, but rather a combination of traditional and iterative. Please keep in mind that a harmonized cadence generally helps everyone involved.

Software Solution for Hybrid Project Management: Microsoft Project + Jira Integration

How can you map traditional, agile and hybrid project management methodologies with software?

If, in agile projects, the project managers use Microsoft Project and the employees track their tasks using Atlassian Jira, an MS Project + Jira Integration makes sense.

The sharing of data between the two integrated systems turns:

• Phases into Versions
• Work packages into Epics

The Microsoft Project Epics are precisely planned as issues in Jira, and the effort is supplemented by, for example, Story Points. The combined story points are transferred, per Epic, back to Microsoft Project. This gives the project manager clarity when planning and later monitoring the completion.

Wondering about the end of POL? Read about Project Online Retirement in 2026.

By the way, it is also possible to synchronize the actual hours reported with the status information for the work packages in this way.

The integration of MS Project with Jira is only one example of how you can use the selected methods to track and manage complex project plans in software.

Our tip: There are ways to integrate trusted, familiar programs. Instead of migrating from one software environment to another, you should find information about the capabilities of integration middleware. An integration would enable everyone to continue using the tool that is most familiar and best suited to their needs – while at the same time producing better data as a basis for corporate management.

Conclusion – Comparing Project Management Methodologies

This article has explained why agile project management methodologies are so in demand these days. You now know the difference to traditional and hybrid planning methods.

The article has provided insight into which methodology is most suitable for a given situation:

• Traditional project management is best when projects can be planned in advance and the requirements are relatively clear from the beginning. Change requests can be handled if there is a good change management process for dealing with them. This method is also well-suited for project environments that are subject to strong laws or highly regulated.
• Agile project management is best in situations where many details are still unclear at the project’s beginning. Here, the details are developed step by step together with the customer in an iterative process as the project progresses.
• The hybrid approach is recommended in situations where the project is easy to divide into sub-projects that can be reliably planned.

To summarize: There is no “one right methodology” that is suitable for every project. You need to choose the methodology best suited to the particular project.

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 your experience with the different project management methodologies been? Please let us know in the comment area below.

Der Beitrag Comparing Project Management Methodologies: Agile, Traditional or Hybrid erschien zuerst auf Blog Project Management for Companies.

This article gives an overview as well as tips on the below topics:

• The different conceptions of agility
• Product visions and roadmap
• Agile fixed price
• Conclusion – Agile IT project management at OEMs

The Different Conceptions of Agility

Top management decides to introduce agile practices such as Scrum, Kanban or DevOps. They commission a governance department to design company-specific models for these methods and provide the necessary staff training. External consultants are likely to be involved in this. After a few months, the concept is in place and the employees have undergone comprehensive training.

Yet, in what way can we impart the method and especially the mindset to the organization to create a common understanding? How do you integrate external partners who may have adapted the theoretical models differently? And how do you motivate employees who have been using different methods for decades and are skeptical of changes?

Learn the difference between agile, traditional and hybrid PM approaches here.

With almost every project start, we are still facing exactly these challenges. The customer’s project managers are renamed Scrum Masters, the stakeholders from the department now go by the name of Product Owner, yet they have not undergone training. And external consulting companies are commissioned for pure development services according to Scrum methodology. Meetings are quickly created, and the first Sprint begins.

Yet, the User Stories are often too unspecific or the Definition-of-Done (DoD) and Definition-of-Ready criteria too generic. In distinct cases, this state continues across several Sprints – after all something needs to be presented to the department – and there is little time to clarify fundamental issues. At this point, an agile understanding at project level alone will not be sufficient.

If company philosophy or culture are contrary to agile values, the change of culture will be difficult to achieve (see Management 1.0 vs. Management 3.0 et al.).

Yet, this is precisely the time which is essential for project success: overall conditions and responsibilities should be discussed and determined upfront – by the entire project team at least. The cultural change still needs to be driven by the entire company, with top management leading the way.

Another interesting read: How to reduce conflicts with agile resource planning

A common understanding of how to approach the project is the basis for future collaboration.

• On what level are the project participants?
• Do processes have to be altered due to lack of expertise or availability?
• How can the project team compensate for this in one place or another?

You do not necessarily have to follow a purely agile approach. Hybrid methods are often more promising, as the participants tend to find the orientation a little easier. As long as there is readiness among the project participants, team and role coaching can lead to a significant improvement in collaboration across the project duration.

Product Vision and Roadmap

 “We work with agile methods, so we don’t need a plan!”

Many of you will have heard this sentence here and there. Yet, agility is not to be mistaken with chaos. It is true that visible increments can be presented faster with an iterative approach and changes can be added to a product sooner, but in the end the product should provide added value to the user. Without a product vision and a clear roadmap indicating which goals should be achieved at what point, it is easy to get lost in the details. At the same time, the various requirements of the stakeholders will become overwhelming.

Without a clear goal in mind, it is easier to stray off track. Therefore, everyone on the team should be familiar with the long-term vision as well as the next intermediate goal. Knowing why you are doing something is a great motivator and helps you stay focused.

As Dan Pink describes in his successful book Drive – The Surprising Truth About What Motivates Us the Purpose is one of the three most important motivation factors in today’s working environment.

Clear goal setting at the project or product start including a roadmap or the creation of a rough milestone plan helps increase the added value of the product and support the Product Owners in their role. The constant comparison of the current product with the product vision helps to better prioritize the Product Backlog and makes discussions with stakeholders easier. In cases of doubt, the actual function of a product will not be greatly improved by placing a blue button in the top right corner or a green button in the bottom left. Do not needlessly waste valuable time and capacity with this kind of issue.

With the aid of methods such as Design Thinking, you will find out the user aspects when creating the vision. You will record these aspects in a Business Model Canvas or for example a Product Vision Board. The Business Model Canvas has the additional advantage that it can be used as a decision paper in the discussion with product sponsors.

Our tip: Let the users verify your vision once it is complete. This helps avoid the risk of losing them.

Agile Fixed Price

The team or even the company have reached a mutual understanding, the product vision is complete and resonates with the entire team. Sounds like it is time to get started. But that would be leaving out sales and the legal department.

Now you need to turn this project construct into a fixed-price package to be able to get service providers on board. Understandably, companies protect themselves in order to establish comparability between providers and transfer part of the project risk to the service providers. The service to be provided, which is not yet specified, is packaged into mini units.

At worst, you take User Stories which will never be implemented in this way as references. The resulting “fixed-price” units, such as Story Points, User Stories or T-shirts, serve as empty shells for future implementation topics. Before each Sprint, you take a blank size M T-shirt and print a logo (User Story) on it that roughly fits the bill. Only time will tell whether the increments between the T-shirts were appropriate.

This is where the stakeholders’ flexibility and wish to collaborate is in demand. A joint estimate by the whole team will increase understanding on both sides. You should also agree up front what services are covered by a Story Point or a T-shirt.

Find more information on fixed price and agile contract models here.

Openness and transparency within the team work wonders. Pay attention to the following points:

• Will efforts for governance and meetings be assigned to the existing User Stories or will they be charged separately?
• Does the estimate apply to pure development efforts or does it include the detailed design and testing?
• What about the subsequent deployment?

You should also address the approach to potential idle times. If budgets are cut overnight or the department has failed to specify User Stories due to vacation, you run the risk that teams can no longer implement efforts or charge for them.

A second technical backlog containing documentation, technical debt or optimization measures such as refactoring or test automation can prevent idle times and will add value to the product.

An agile comment on the fixed price topic:

Unfortunately, a lot of effort goes into the clarification of pseudo-fixed prices and the tasks of correctly mapping and accounting for this in organizational terms. However, this does not add value to the product that is to be developed. Put together a team commissioned to work full time on the product for the expected project duration. In this case, it is possible to implement a greater number of valuable functional and non-functional requirements at the same risk.

Ever heard of agile PMOs and traits they share with hummingbirds? Read now.

Conclusion – Agile IT Project Management at OEMs

The agility of OEMs and suppliers continues to advance relentlessly. It is practiced in relation to processes, predominantly in IT departments but not only there. The employees have caught on to the idea. Now, the only challenges are to increase the maturity level and especially to work on the agile mindset.

In summary, you could use the following aspects to increase the maturity level, strengthen the mindset and maximize project success.

• Create a consistent understanding (of agility) on the team at the project or product start. This does not necessarily have to be Scrum by the book.
• Make sure you formulate a clear product vision and define a milestone plan. This allows you to check whether your work contributes to the product and helps you keep focused.
• Define an estimation procedure together with the whole team and define the service description of the billable units (Story Points, T-Shirts or User Stories). This enables you to avoid unnecessary discussion during implementation and to build a fixed-price construct including external services.
• Try to reduce idle time through optimization, technical improvement and further training of the team. Thus, you can keep the team on the same utilization level and do not risk the downsizing of a winning team.

Any questions about agile IT project management? Just leave a comment below. We will respond as soon as possible.

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:

Nils Schweizer has been working in the project and service management environment for years since finishing his business degree and B.Sc. He has completed certifications in Prince2, ITIL V3 and PSM1. After getting valuable insights into the OEM world at MAN, BMW and Siemens, he supported Sulzer GmbH in setting up the US subsidiary. Since 2018, he has been directing the company’s project management across all locations.

Find out more about Nils Schweizer on LinkedIn.

Der Beitrag Agile IT Project Management at OEMs – a Status Quo? 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.

• What is “hybrid project management”?
• Which scenarios are best suited to hybrid project management?
• Roles and processes in the traditional project lifecycle
• By contrast: agile work methods
• Resource and capacity planning in agile projects
• Hybrid project management: optimally combining the two methods
• Hybrid project management: example
• Traditional and agile methods within a company: using both methods
• Combining both methods within a single project
• Agile, traditional or hybrid approaches in multi-project management?
• Conclusion and recommendations

What Is “Hybrid Project Management”?

“Hybrid project management” refers to methods that combine planning strategies from the traditional PM environment with the agile me­thodol­ogy’s flexible approach.

Click to tweet

A hybrid approach to project management thereby integrates the various methods (such as PMI and Scrum) or the use of diverse elements from various methods (such as User Stories from Scrum with the V model XT software specifications).

Which Scenarios Are Best Suited to Hybrid Project Management?

Many organizations function in an environment in which traditional processes have evolved over time and compliance is required with broad obligations and required standards. For projects, this means that there is a focus on choosing methods that clearly define the plans and project goals and require that everything is documented. Or methods are prescribed by an external source, such as a regulatory authority.

However, times are changing. As software continues to play an increasingly important role in hardware products, agile methods ‒ with their iterative processes and shifting objectives from sprint to sprint ‒ have become increasingly popular.

Combining traditional methods for some of the subprojects with elements of the agile methodology (such as Scrum) lets organizations take advantage of the best of both worlds to find the solutions best suited to their individual needs. This can enhance the project’s benefits by, for example, achieving better results, reaching the goals faster, or minimizing expenses.

Note: The PMI study “The Drivers of Agility” found that companies operating with a high degree of agility bring significantly more projects to a successful conclusion than those that do not. Of the companies exhibiting a high degree of agility, 68% used agile methods, 71% predictive, and 72% used a hybrid methodology. Among the companies exhibiting a low degree of agility, only 41% used agile methods, 45% predictive, and 51% hybrid methods.

Roles and Processes in the Traditional Project Lifecycle

• Project sponsors
• A project manager
• Several team leaders
• Team members
• A Project Management Office (PMO)

One or more project sponsors define the overall goal. The objectives are then to narrow these goals down to actual targets, with the expectation that these will be met. It is important to determine what skill sets are needed and when and then find out when these will be available.

The project is then prioritized and considered when resources are allocated. Team members are different for each project, as each member is chosen based on the skill sets needed for that particular project. The team leaders from the various departments need to see what resources they need to handle their daily operations to find out what resources can be made available to the project.

As the project progresses, some deadlines may need to be modified and other elements changed, but the focus should always be on ensuring that the specified goals are met by the given deadline. Resources can be withdrawn from lower-priority projects and reassigned to top-priority projects so that team members devote most of their energy to those projects having the highest priority.

It is important to keep an overview of all the current and new projects and their resource utilization. In addition, close coordination is required to optimize resource utilization with regard to the latest requirements and circumstances.

Any changes to the project are carefully tracked and, together with the sponsors and / or end customer, evaluated with regard to added value and additional cost as compared to the original specifications. Status reports are prepared to show progress on the delivery of existing orders. Detailed schedules are created in the form of Gantt charts and milestone trend analyses. Risk analyses, with recommendations for avoiding these risks or minimizing their effects, may also be included.

The final result is generally some form of acceptance document that compares the delivered result with the original order. If there are deficiencies, these will be listed in the document and subsequently corrected. Sometimes these deficiencies are minor and can be accepted, but sometimes 100% compliance with the original specifications is required because, for example, the deliverable is a bridge that must stand or a crash test that must be withstood.

In the end, there is a final meeting involving the team members, project managers and sponsors to discuss and document the lessons learned so that future endeavors may benefit.

This is a good time to ask yourself what can be done better the next time. Achieving goals and allocating the required resources is completely normal and necessary, right? Yes, if the goals are absolutely clear and these are the right measures for achieving those goals, then the traditional approach is the best one.

However:

• What if you are expected to deliver results that can be obtained in several ways?
• What should you do if new insights and technologies become available during the project?
• How can you integrate these into the existing project plans to deliver a better solution?
• Would it not be great if there was some way to get the sponsors, customers, and users to all agree to these changes without risking non-conformance with the specifications?

Sometimes it is just not possible to clearly define what the deliverable should be because those involved themselves do not know exactly what they want or need. Have you ever not realized you were hungry until the scent of food made you crave a particular dish? Suddenly, you knew exactly what you wanted.

Another interesting read: Agile project management, traditional or hybrid?

By Contrast: Agile Work Methods

Agile approaches are much more common today, especially at the product development stage in software development or other similar areas. This often applies to cloud solutions, which must provide uninterrupted service.

Increasingly, the approach is used in other high-tech and complex environments as well. The traditional approaches described above are just not suitable in cases like this.

Therefore, it has become prevalent, as in agile approaches, for a fixed team to develop iterative versions of a product while the users are already using the product on a daily basis. After all, the users also want to see ongoing progress.

A team is often put together only once and then continues to live for and with this software, just as other teams do with their products. The teams are rarely ever reorganized.

Looking at the roles in agile methods (such as Scrum), we can identify the following:

The Product Owner

• Makes all the decisions regarding the product
• Prioritizes and maintains the backlog
• Is constantly available

The Scrum Master

• Manages the process
• Removes impediments

When it comes to resource planning, the following applies: strategic and tactical planning is also necessary for agile teams. Staff is needed for ongoing projects, new staff must be trained, etc.

You might also be interested in Agile IT Project Management at OEMs.

Remember that no one is permanently available 100% of the time. Plan for absences due to vacations, etc. What is the best way to handle resource planning and capacity planning?

Resource and Capacity Planning in Agile Projects

Agile methods offer an advantage in resource planning: their fixed product and project teams, as well as the fixed cadence, make overall planning and the shifting of staff between projects much easier.

Our tip: Take particular care to find a shared rhythm across projects and thus achieve harmonization. This makes it much easier for staff to shift from one project to another.

Agile teams are mostly self-organized and have the experience necessary to estimate the effort involved. This starts with a rough estimate that becomes more detailed in the course of the project. The teams report when something has been completed and give feedback in reviews and retrospectives.

Together with the product owner, they gather stakeholder feedback in review meetings.

Kick-off meetings are no longer required in agile environments.

Learn more about Project Resource Management.

Regular sprint planning, reviews, and retrospectives, on the other hand, are mandatory.

In addition, the development team meets daily to discuss progress with regard to the Sprint Goal.

The only remaining targets can be found in the Product Backlog or the Sprint Backlog as a subset for each sprint. If something is not documented in the backlog, it will not be done.

Communication with the stakeholders is not only through the reviews but also via public boards with Sprint or product burn down charts. This is why the traditional reports with their schedules, costs, and status are superfluous at best.

Yet, what may be missing is a meaningful multi-project overview.

Hybrid Project Management: Optimally Combining the Two Methods

How can you combine these two different worlds?

There are many approaches to introducing hybrid methods:

1. Concurrent Use of Traditional and Agile Methods:

• Some business units always use traditional methods (e.g. consulting). Others always use agile methods (e.g. software development).
• Some projects use a traditional approach, others an agile one.
• Some parts of a project are implemented in a traditional way, other parts using agile methods.
• High-level planning employs a traditional approach, detailed planning an agile one.

2. Combining Traditional and Agile Methods in a Single Project:

• In traditional projects:
  • Closer coordination with users and more frequent, implementable intermediate results
  • Regular meetings to discuss progress (not necessarily daily – once a week is a good start)
  • Retrospectives (Lessons Learned) after each status update meeting, not just at the end
  • There is a fixed team for the entire duration of development

• In agile projects:
  • Scrum Masters also serve as project managers in the traditional sense
  • A Backlog is created for each project phase rather than as a specification for the overall product
  • Project planning is synchronized with the sprint lengths
  • Projects are planned using phases and milestones – at a higher level than the sprints and in addition to them
  • There are status reports and milestone trend analyses for management and for the stakeholders
  • (By the way, many agilists are unhappy with the latter two examples, as they can water down the basic agile principles).

A general note: Are the customer’s requirements uncertain and unclear? Is the approach to a solution for the project still unclear and new? Agile methods are particularly well-suited in this case, as they were developed for exactly this type of situation.

Our tip: Look at the first option in the above list. Having some business units use traditional approaches while others use agile ones is probably one of the most seamless and common implementations of hybrid project management. This usually ensures high process stability.

Hybrid Project Management: Example

For customer consulting projects, you always use traditional methods whereas the endeavors focusing solely on product development follow agile principles. What to bear in mind: customer wishes have to be aligned between the business units.

This means that the sales department must have a say in the release planning.

Traditional and Agile Methods within a Company: Using Both Methods

Please note: Frequent changes between traditional and agile approaches from one project to the next pose a risk to the process stability.

Therefore, another option is to combine methods in a meaningful way – rather than changing between methods in projects. To give you an example:

• Traditional concept, specification and implementation for the hardware
• Agile software development
• Traditional acceptance test

or:

• Agile concept and specification
• Traditional implementation and acceptance test

or:

• Traditional methods for everything up to the integration
• Agile integration

Our tip: If you use hybrid approaches within a single project, follow this proven approach: use agile methods for unclear parts of the project while using traditional methods for the clearer parts.

Combining Both Methods within a Single Project: Using Traditional Methodology for Hogh-Level Planning and Agile Methodology for Detailed Planning

Another approach has been proven successful for using hybrid methods in the same project:

• Use traditional methods for high-level planning as a kind of superstructure.
• Add an iterative element afterward using agile work methods.

This approach lets you continue to plan milestones and status meetings. While at the same time benefiting from the advantages of agile work methods.

Making the meeting frequency rhythmic also will minimize friction and the general coordination effort – which ultimately increases productivity.

A survey on hybrid PM conducted during one of our webinars held in April 2018 involving 256 respondents (multiple answers possible) revealed that:

• 11% of the participants carried out their projects according to the defined methods of that business unit
• 41% decided the method project by project
• 40% chose the method based on the project situation
• 41% did their high-level planning with traditional methods and used agile ones for their detailed planning
• 18% were still unsure

Our tip: Separate the methods clearly, depending on the business unit. This will provide the highest process reliability. It is usually a good way to get started.

Agile, Traditional or Hybrid Approaches in Multi-Project Management?

Multi-project management will always require an overview of the status, necessary decisions, and delivery dates.

• Status
• Required decisions
• Delivery deadlines

Problems concerning the project status need to be quickly and clearly discernible (e.g. with the aid of a red traffic light symbol).

This is another difference. In typical (multi-) project environments, traditional methods will always be necessary. In the course of product development for “small-scale projects” from version to version, it is a little different. They can be planned with agile methods without any problems.

As agile environments do not provide methods for multi-project management, further questions are unnecessary.

Conclusion and Recommendations

This article has introduced you to ways in which hybrid project management – a mix of agile and traditional approaches – can be applied in practice.

You have learned that there are many ways to apply hybrid methods. For example, you can use traditional and agile approaches concurrently in different business units or combined within an individual project.

There are situations in which traditional methods continue to make sense – despite growing agility.

Our tip: Above all, we recommend that you introduce different suitable methods for the different areas of your organization.

Moreover, it is essential that you closely involve all the relevant departments (such as sales) right from the beginning.

The best strategy is to introduce the methods step by step and to find a good team rhythm for the project.

Another important point: special situations or environments often require a customized combination of methods. It is always better to find a tailored solution for every individual project (as in our examples above) than to impose an approach from an external perspective.

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 hybrid method do you use, and would you call it a successful one? We look forward to reading your comments below.

Der Beitrag Hybrid Project Management – Combining Agile and Traditional Methods erschien zuerst auf Blog Project Management for Companies.