SAFe 4.5 + JIRA

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/332470715
FULL SAFE V4.5 IMPLEMENTATION IN JIRA
Preprint · January 2018

DOI: 10.13140/RG.2.2.25990.22089
CITATIONS READS
0 408
1 author:
Edoardo Gori
Ecole Supérieure d'Ingénieur en Electronique et Electrotechnique - Paris
2 PUBLICATIONS 0 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Big Data Deployment Model for the Architecture’s Optimization: A Pharma Manufacturing Business Case View project
All content following this page was uploaded by Edoardo Gori on 17 April 2019.
The user has requested enhancement of the downloaded file.

FULL SAFE V4.5
IMPLEMENTATION IN JIRA
MoTIS 9 June Project 2018
Table of Contents
Overview of a Traditional Organization 4

Introduction to Full SAFe v4.5 Framework 5
Introduction to Jira Project Management Tool 6
Introduction to Scrum Methodology 6
Introduction to the Kanban Method 7
SAFe v4.5 Levels Mapped to a Traditional Organization 8
Team Level 8
SAFe Roles Mapped to a Traditional Organization 9
Program level 11
Large Solution Level 13
Portfolio Level 14
Roadmap: How to transition from a Traditional to Agile Organization by using Full SAFe v4.5 16
Jira Implementation 20
Case Study: Implementing Full SAFe v4.5 in Jira 20
Issue Type Configuration 20
SAFe v4.5 Portfolio Level Implementation in Jira 25
SAFe v4.5 Large Solution Level Implementation in Jira 28
SAFe v4.5 Program Level Implementation in Jira 31
SAFe v4.5 Team Level Implementation in Jira 35
Financial and Burndown Metrics 43
Recommendations 44
Alternative Tool for Implementing Full SAFe v4.5 44
Appendix A: Disadvantages and Risks of a Traditional Organization 48
Appendix B: How to install and configure Jira on a local machine 51
Appendix C: How to install and configure portfolio for Jira 63
Appendix D: How to install and configure Structure for Jira 64
Appendix E: Potential Issues Installing and Configuring Jira 65
Appendix F: Steps to implement Full SAFe v4.5 in Jira 69
Appendix G: Full Structure of XYZ Bank Jira Implementation 70
References 85
Overview of a Traditional Organization
A traditional organization operates in a sequential and linear way in which they manage their projects.
Each project consists of a series of predefined phases and no phase begins until the prior phase is
complete. The main characteristics of a traditional organization is that work is planned extensively up
front and then executed, in sequence, adhering to requirements, to deliver the project in a single life
cycle. All information must be thoroughly documented and made available to everyone that is
participating on the project. Documentation is another key point of a traditional organization, in fact it
should take place
throughout every phase of
the process, ensuring that
everyone involved is on
the same page despite the
sequential progression of
the project. There is a lot
of bureaucracy and a
specific reporting line;
hence many more roles
exist in a traditional
organization and on a
traditional project than in
SAFe which is explained in
detail further in the
report.
The phases that make up

the Waterfall model are
Initializing, Planning,
Executing, Monitoring and
Controlling, and Closings
as described by the
PMBOK to the right.
Introduction to Full SAFe v4.5 Framework
The Scaled Agile Framework, or SAFe, is a template for scaling Agile principles and tools to large
organizations. SAFe was developed to cover entire organizations working on smaller-scale solutions
employing 50–125 practitioners, to large complex solutions that require thousands of people. SAFe is
based on Lean-Agile principles and values and provides guidance for the roles, responsibilities, artifacts,
and activities necessary to achieve better business outcomes. The framework operates on four levels:
portfolio, large solution, program and team. Each of these levels are explained in detail in SAFe v4.5
Levels Mapped to a Traditional Organization. Projects are undertaken in an Agile manner where teams
are empowered to be self-managing and the focus is on delivering business value as early as is possible.
Quality is also a major concern of the Agile approach and is never compromised. Management is more
about empowering as opposed to command and control as in a traditional organization.
Introduction to Jira Project Management Tool
Jira Software is an agile project management tool developed by Atlassian that supports the
implementation of any agile project management method. With agile dashboards and reports, it allows
the users to plan, monitor and manage all agile software development projects from a single tool.
Introduction to Scrum Methodology
Scrum is a framework that allows teams to deal with complex problems in an adaptive way while
delivering products with the highest value.
1
The framework consists of a Product Backlog in which features are prioritized according to the
customer’s criteria. The prioritized backlog is split into sprints (timeboxes) in order to ensure the
features with the highest value are built at the beginning. This prioritization requires the participation of
the Product Owner and the customer. Once this prioritized backlog is finalized, the product owner and
the team need to agree which feature(s) can be allocated to the next immediate sprint while ensuring its
delivery. During sprints, the team has daily meetings, called Daily Scrum, to show and share their
progress towards the final product. Finally, at the end of each sprint, there are two meetings that occur.
The first meeting is called Sprint Review in which verification of the completion of all the features set
out by the team to complete takes place, and the second meeting is called Sprint Retrospective where
the team analyzes of how they performed during the sprint and identifies things could have been
managed differently.
1
Product Backlog: a list of all the features that needs to be built to finish the product
Introduction to the Kanban Method
Kanban is a method to for work management introduced by Toyota in the late 1940’s. The Kanban
method consists of 4 principles: visualize the work, limit work in progress, focus on flow and continuous
improvement.
Visualize the workflow states that all work need to be mapped in order to visualize the current status of
tasks from the initial request to a final deliverable. This visualization is generally done on board using 3
columns. A “To Do” column, where all the tasks are mapped at the beginning, a “Work In Progress”
column that visualizes the jobs currently being developed, and finally, a “Done” column that shows the
jobs already finished.
The second principle, “Limit work in progress”, helps us improve the way in which jobs are managed by
restricting the number of tasks that can be done in parallel. Activities can only be moved to from the “To
Do” column when there is sufficient space in the “Work In Progress” column. The maximum number of
tasks allowed in this column is defined prior to the project and under no circumstances can this be
compromised.
The third principle, “Focus on flow”, allows the team analyze their work and progress and improve the
quality of upcoming sprints. The Kanban board can provide the team with metrics that are generated by
using the work in progress limits and team policies to figure out the team’s velocity and progress rates.
Finally, the fourth principle, “Continuous improvement”, states that by having analyzed and extracted
the metrics of the team and work, changes can be made to improve the team’s effectiveness.
SAFe v4.5 Levels Mapped to a Traditional Organization
Team Level
The Team Level works following the standard scrum methodology (the teams can also work in Kanban
depending on the organization). The Team Level has Agile teams that power various Agile Release
Trains, ARTs, (explained in the Program Level).
At the SAFe Team Level, the work is undertaken by Agile Teams which are cross functional and work
together to deliver working systems in two-week timeboxes called Iterations (the basic building blocks of
Agile projects). Each iteration is a standard, fixed-length timebox, where an Agile Team delivers
incremental value in the form of working, tested software and systems. Five iterations make up one
Program Increment, PI, (although the team is free to decide how many they want in a PI). A PI is a larger
timebox during which Agile Release Trains (in the Program Level) deliver value through the incremental
delivery of tested, working software and systems that have been developed in each increment in the
team level.
The content for the iteration is determined by the Product Owner who is in charge of the team’s product
backlog (which translates to the complete control of scope from the traditional standpoint). The goal of
the iterations are to deliver user stories which deliver value to their customer. Each Agile team is
supported by the roles from the Program Level which results in the team being fully capable and
responsible for defining, building, and testing stories from their specific backlog. The iteration starts with
a planning meeting where the team decides what user stories they can deliver by the end of the
iteration. The team is then left to self-manage and begin executing the agreed work. Each day the team
meets to review and discuss their progress in a Daily Scrum meeting and at the end of the iteration they
demonstrate the results to the Product Owner to make sure they have delivered what had been agreed
and committed. Then they get together to retrospect what they can improve for the next iteration
before starting the cycle again with a new planning meeting. All of this is guided by a Scrum Master who
makes sure the team works smoothly within the process and that it keeps improving.
This is the main concept of Scrum; a framework that allows teams to deal with complex problems in an
adaptive way while delivering products with the highest value. The Scrum Methodology was explained in
Introduction to Scrum methodology. In Agile development and at the SAFe team level, quality is the
main priority of the teams. The teams focus on delivering business value as early as possible while never
compromising on quality. Teams can also work with a Kanban alongside Scrum. Kanban is a method for
work management which visualize work to be done, limits work in progress, and focuses on flow and
continuous improvement. Kanban has been explained in detail in Introduction to the Kanban Method.
SAFe Roles Mapped to a Traditional Organization
SAFe Team Level Roles:
● Development Team: Team composed of people with cross-functional profiles who are in charge of
the delivery of user stories, features and epics. The idea being that this team is empowered to be
autonomous and can deliver the entirety of the stories with minimal external intervention. They
participate in the PI planning, develop and test the user stories that were committed to be done by
the end of the PI, help the Product Owner to write the acceptance criteria, refine the user stories
and finally create and develop the PI iteration plan.
● Product Owner: Participates in the program backlog prioritization (PI planning) and prioritizes the
product backlog of the team. The Product Owner is in charge of writing the user stories, writing
story acceptance criteria, accepting and rejecting delivered user stories, and maintaining the
product backlog of the team. The Product Owner coordinates dependencies with other Product
Owners to unblock the tasks for their respective team.
● Scrum Master: This is the person who is in charge of teaching everybody the Scrum Methodology
following the lean-agile process, coordinate with the other development teams on the Agile Release
Trains, report the status of the project to the management, facilitates the communication between
all the members of the team, facilitates the meetings, and promote SAFe qualities practices.
● Agile Team: It is the team which is in charge of delivering the product increment in each Program
Increment iteration and it is comprised of the Scrum Master, Development team and Product
Owner. The agile team define the work, estimates the size and complexity of work that needs to be
done, make the technical design and architecture for the work, develop and test the work and
continuously improves its process.
Traditional project management roles:
● Project Manager: Manages the project by creating detailed project plans up front and uses project
management tools to delegate work and oversee the team working on the project. The team is
delegated work through a command and control management style as opposed to Scrum where the
team is self-managing. The Project Manager is accountable for project success and failure and holds
weekly review meetings with their team as opposed to the Scrum Master who holds daily meetings.
However, similarly to the SAFe role of Scrum Master, the Project Manager acts in a capacity to
address and mitigate any major team issues. The Project Manager is responsible to the quality of the
end product whereas in an Agile team, each team member is responsible for ensuring the quality of
the end product.
● Sponsor: The project sponsor deals with the benefits of the project. A project sponsor is usually at a
high position in the organizational chart, funds the project but is not involved with the details of the
project.
● Development Team: Writes the code and are engaged on the project after planning has been
completed and the project is ready for development. They make use of the documentation on
requirements to understand what the requirements are. They interact with the Business analyst for
additional questions and work with the designs produced by the architect. They are often assigned
tasks from Project Manager with specific due dates.
● Project Team: Similarly to SAFe, the Project Team is comprised of all other roles discussed above.
● Project Management Office: The PMO provides guidance and advice for project managers, they
ensure project management standards are set up and followed, gather data and information for
management review, and finally facilitate the portfolio management process.
Traditional Roles SAFe Roles
Project Manager (Scope) and Product Owner and Sponsor

Sponsor
Project Manager (Admin) Scrum Master and Product

Owner
Development Team Development Team
Project Team Agile Team
Project Management Office No equivalent SAFe role

Program level
The Program Level is similar to the Team Level, in the sense that there are teams comprised of multiple
teams working to deliver a larger system together. Teams can range from 50 to 125 people. This team of
teams is called an Agile Release Train or ART and it will also timebox its effort into Program Increments
or PIs which are 5 iterations by default.
The content for each PI is determined by a Product Manager in the Program Backlog in the form of
Features and will provide most of the content for the Team Backlogs. The ART is governed by an RTE or
Release Train Engineer who acts as the train's scrum master, ensuring it runs smoothly and remains on
track. The RTE role can be described as the Program Manager of the program level. Each PI starts with a
planning meeting in which all members of the teams get together to hear the vision and roadmap of the
train and the features for the upcoming PI. Each team then plans what objectives they can achieve in
this PI, while identifying dependencies with other teams on the train as well as risks. The teams commit
to these PI Objectives as a group providing visibility to Business Owners and Customers of what they can
expect in this PI.
To make sure the train will meet its objectives, there is both a bi-weekly meeting of the Scrum Masters
and the Release Train Engineer and a system demo at the end of every iteration. This is a demonstration
of the integrated system which ensures that one team isn’t running ahead but that the whole train is
iterating together. Moreover, Solutions can be released on demand, during, or at the end of a PI, based
solely on the needs of the business. Frequent or continuous integration of the work from all teams is the
ultimate measure of progress. Since Release Trains should always stay on track and proceed in the work
as quickly and efficiently as possible, it's necessary to provide adequate architecture and infrastructure.
In fact, each PI is also used to define what is needed in order to achieve our goals in the following PI.
This concept is described as an architectural runway and is facilitated by the train’s System Architect.
The final iteration of a PI is called an IP Iteration or Innovation and Planning iteration. The Innovation
part is the time for the teams to engage in creative ideas, it's the time for ship-it days or hackathons. The
planning part is when the ART demos the accomplishments for the PI, provide maintenance for the train
by retrospecting on how it can improve the collaboration in the next PI and finally plan the next PI. The
IP iteration also serves as an estimation guard band to make sure the teams deliver on their
commitment.
SAFe Program Level Roles:
● Release Train Engineer: It is the person who is in charge of training the teams, scrum masters in
Lean-Agile practices and mindset, facilitates the PI planning events, summarize the team objectives
into PI objectives, escalate and track impediments, coordinate with Product and solution managers,
product managers and product owners to ensure strategy and execution alignment and report
status to the Portfolio Management.
● Product Manager: Person who is in charge of the program backlog having the authority to make any
modification on it, prioritizing, adding and removing features. This role has to understand the
customer’s needs, validate the solutions, participate in PI planning by transmitting the feature of the
solution, define releases and program increments, work with the System Architect to understand
that there has to be some work to do in the enabler stage for the next program increment. In fact,
this person acts as the product owner in the program level.
● System Architect/Engineer: Role that is in charge of providing technical enablement for ART. The
main functions of this role are to participate in planning, definition and high-level design of the
solution, define subsystems, interfaces to interact with the solution context, participate in the PI
planning, pre and post PI system deployments and coordinate with the product managers to
determine the capacity of allocation of some work to be done.
Traditional project management roles:
● Sponsor: Most senior member of the program organization. Has crucial responsibilities in a project
such as approving funding, resolving strategic issues, appointing the Senior Responsible Owner,
approving a program's progress, and signing off at the end of program closure.
● Senior Responsible Owner (SRO): Often a sponsor or member of the sponsoring group who
represents the main sponsor in the program organization and is ultimately responsible for
foreseeing that a program meets its overall objectives. The SRO makes decisions on behalf of the
sponsors.
● Program Manager: A “super” project manager responsible for planning and governance and
overseeing the successful delivery of a program's output. The role is mainly operational. Some of
their responsibilities include managing risks and issues, daily program management throughout the
lifecycle, defining program governance, managing and utilizing resources across a program, and
managing the program’s budget to name a few of the most important ones.
● Business Change Manager: The Business Control Manager plans and manages the realization of
benefits through the new capabilities brought by the projects within the business practices. Some of
the BCM responsibilities include defining benefits that will realize strategic objectives and
developing this benefit realization plan, maintaining focus on overall benefits realization, advising
the program manager on whether the outcomes of the program will lead to benefits realization, and
managing business continuity.
● Program Management Office: They have a similar focus to the project management office but on a
higher level and larger scale with wider perspective. Their responsibilities include setting up tools
and standards for managing the program, planning, tracking and reporting on outputs and
outcomes, tracking risks and issues, and managing cross-project interdependency to name a few.
Traditional SAFe
Program Manager Release Train Engineer
No equivalent traditional role System Architect/Engineer
Business Change Manager No equivalent SAFe role
Program Management Office and Product Manager

Sponsor and Senior Responsible Owner
Large Solution Level
The Large Solution Level provides the means to coordinate ARTs that are building an even larger
solution, which a single ART can’t deliver by itself. At this level we have the Solution Manager as the
content authority, the Solution Train Engineer as the coach and guide and a Solution Architect to help
ensure good architecture is used. The large solution runs on the same PI cadence as the ARTs and has
planning, solution demo and inspect and adapt for cross-ART capabilities.
Since, as previously stated, to build large and complex solutions requires the coordination of multiple
Agile Release Trains (ARTs), the work is organized in Solution Train. This organizational structure
provides support for the ARTs using the solution Vision, Backlog, and Roadmap, and an aligned Program
Increment (PI). SAFe provides examples of the work that can be managed by a Solution train include
medical devices, automobiles, commercial aircraft, banking systems, and aerospace and defense
systems.
● Customer: As the ultimate buyer of the system, involving the customer is an imperative part of
Lean-Agile development to ensure business value is delivered.
● Solution Architect/Engineer: a single individual or small team that defines a common technical and
architectural vision for the solution being developed.
● Solution Manager: Solution managers work with customers to understand their needs and how to
deliver business value to them. They elicit the requirements (both enablers and capabilities) from
the customer and create a solution vision and roadmap, and finally guide the work through the
solution Kanban. The SOlution Manager has the content authority for the Large Solution level.
● Solution Train Engineer (STE): A servant leader and coach who is responsible for guiding all ARTs and
suppliers through the work that must be done.
● Supplier: An internal or external organization that develops and delivers components, subsystems,
or services which helps Solution Trains deliver solutions to customers.
Traditional Organization Roles:
The SAFe Large Solution level does not exist independently in a traditional organization. In a traditional
organization, this level is included in the program level.
Portfolio Level
The SAFe Portfolio Level contains the principles, practices, and roles needed to initiate and govern a set
of development Value Streams. Program Portfolio Management helps dictate direction for all
underlying Value Streams, by deriving strategic themes from the enterprise strategy and allocating
budgets to the large solution to support these themes. They also manage across the large solution
initiatives which impact several solutions in the form of Epics.

● Lean Portfolio Manager (LPM): An individual with the highest level of decision-making and financial
accountability for the products and Solutions in a SAFe portfolio.
● Enterprise Architect: Promotes adaptive design, and engineering practices and drives architectural
initiatives for the portfolio. Enterprise Architects also facilitate the reuse of ideas, components,
services, and proven patterns across various solutions in a portfolio.
● Epic Owners: Responsible for coordinating portfolio Epics through the Portfolio Kanban system. They
define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved,
facilitate
Traditional Organization Roles:
● Portfolio Management Team: composed of the Portfolio Manager, and any other individuals with
broad knowledge of projects undertaken by the organization for example the Program Managers.
● Portfolio Manager: In charge of the Portfolio Management Team. The Portfolio Manager oversees
the health, integration, and delivery of all projects inside the portfolio. They communicate with
Project Managers, report to the Executive Team, and make recommendation for the project.
● Program Managers: An individual who is responsible for the management of various groups of
projects dedicated to similar goals or with similar characteristics. They verify projects costs, risks,
and value for projects in their program. Multiple programs may exist with a different Program
Manager responsible for each group of projects.
● Project Managers: Person(s) responsible for the daily management of individual projects. They
communicate the project status and proposal data to the Program Managers and Portfolio
Managers.
● Resource Managers: Person(s) concerned with capacity management. They are responsible for
supplying skilled resources for conducting projects.
Traditional SAFe
Portfolio Manager Lean Portfolio Manager (LPM) and Epic

Owners
Program Managers No equivalent role
Project Managers No equivalent role
Resource Managers No equivalent role
No equivalent role Enterprise Architect
Roadmap: How to transition from a Traditional to Agile Organization by

using Full SAFe v4.5
SAFe has defined 12 main steps in the journey of a company moving from the traditional approach to
Full SAFe methodology. These steps will set up the basis for a successful transition and adoption in the
organization.
The figure below describes the different steps. Each step is explained in detail below.
STEP 1: REACHING THE TIPPING POINT
Before any adoption of Safe can be done, there must be a deciding moment in which the organization
makes the choice to move to SAFe. This point is known as the tipping point. This point is critical in the
SAFe transition process because beyond this point, a significant and unstoppable effect and change will
take place. The tipping point is reached when a company needs a radical change in the project process
and when the employees in the company would not resist the implementation of a new work
methodology.
Two elements may determine the need for a change to Safe
● A burning platform: where the company is failing to succeed
● Proactive leadership: The key success factor of any enterprise is to be able to improve processes are
already in place in the company. In the case where the change is not guided by a burning platform,
the company leadership must always create and maintain a sense of urgency that will imply the
necessity for change and motivate towards the adoption of the SAFe methodology from each
individual in the company.
Once the tipping point has been reached, the following steps are more complex.
After reaching the trigger for the adoption of the Safe methodology, the next step is to build the
supporting teams and roles that will lead the change in the company. To be able to support the change,
the leadership must establish a vision for change. These will principally result in three key benefits:
● Establishing a purpose
● Motivating the team
● Create alignment and put everyone on the same page
It is crucially important for the company to be able to identify and highlight the benefits of moving to
SAFe, especially at the economic level. Any decision made within a company is intended to help increase
revenues and provide a return on investment.
After having established this first principle of change, the management needs to designate the new
process ambassadors. These ambassadors will need training on the new approach and create a coalition.
The next principle is to create a coalition that will be the torchbearer of SAFe in the company. This group
will be made of Leaders who set the vision, show the way and remove impediments to change
practitioners, managers, and change agents who can implement specific process changes. They will
provide:
● Sufficient organizational credibility to be taken seriously
● The expertise needed to make fast, intelligent decisions
STEP 2: TRAIN LEAN AGILE CHANGE AGENTS

The first group made of change agents will be trained on how to effectively use and apply the SAFe
methodology principles and practices. SAFe has a certification designed especially for Lean Agile agents.
At the end of the training course, the lean agent will have the capability to train, guide and motivate all
the other stakeholders of the company.
STEP 3: TRAIN EXECUTIVES, LEADERS AND MANAGERS

For a change to be successful, it needs to be highly supported by the managing team and the leaders of
the company. The Lean Agile mindset with its different principles have to be mastered by this team.
Their main responsibilities are to lead the way, empower the individuals, minimize constraints, establish
the new decision-making framework which is more agile and finally also motivate the team. Finally, SAFe
requires a specific training to teach the leaders the new skills and competencies needed to fulfill their
new functions.
STEP 4: CREATE A LEAN AGILE CENTRE OF EXCELLENCE
This can be summarized by the creation of a team responsible for implementing the new agile way of
working in the organization. The size of the team will vary according to organization size. The main role
of this team is to empower the organization to actually define and launch the different ARTS. It is
usually part of the Agile PMO. The team is also strongly involved in the continuous improvement process
defended by Agile. The team is mainly cross -functional.
Once all the main teams have been built, the following steps are to actually implement the framework
and apply it in the different activities.
STEP 5: IDENTIFY THE ARTS AND VALUE STREAMS

This step can be summarized in two sub steps:
● Identify the ARTS and value streams: Operational value streams, the systems that support them and
the people acting on those systems must be identified. A clear mapping must be done between all
the elements previously cited. Then we can move on defining the development streams which can
be defined as the development group of people for the different systems. The number of
development teams will then be defined according to the number of systems and also according to
how the requirements are related to each system. In the case where one requirement is tied to all
the systems we will have one development team on the project.
● Agile release trains will be formed to realize the already defined value streams. While in small
enterprises all values streams can fit in one ART, in larger companies, the value streams are split into
many ARTS. In that particular case, the trains should focus on a single system or a group of similar
services in the value.
STEP 6: CREATE THE IMPLEMENTATION PLAN

After finalizing the teams, the value streams and the ARTs, the following step is concerned with the
implementation plan. This is where we actually start the real work. The first value stream is selected and
thoroughly analyzed to identify all the surroundings. The first ART is designed and a preliminary plan is
established. This is essentially breaking the PI plan into more details. All stakeholders must be involved
in this.
STEP 7: PREPARE FOR THE ART LAUNCH

Once the plan is established we will start with the first ART. The main activities of this step are to define
the ART, set a launch date and a program calendar, train ART leaders and stakeholders, establish the
agile teams, train the different leaders (product owners, scrum masters, product managers), and
prepare the program backlog.
STEP 8: TRAIN TEAMS AND LAUNCH THE ART

Next, the team members are trained. At the end of the training, every person involved should have
acquired the necessary competencies to successfully carry out their tasks. The SAFe approach is now
well understood, and a clear path is established through the planning. The first Program Increment, PI,
planning session is organized. The PI planning session with all stakeholders will bring all the team
together and create the bond.
STEP 9: COACH ART EXECUTION

Even though people have been trained, it doesn’t make them Agile. Therefore, the next step is
concerned with guiding the team during the ART execution. It is all about coaching the people involved
in the ART, managing program backlog in an effective manner, encouraging, supporting, motivating,
guiding on agile best practices. A key element at this stage is the ‘’inspect & adapt workshop’’. This is
where everyone will learn how the PI went, how the teams performed against their PI objectives, how
well the organization is adopting the SAFe methodology, and how the solution they developed really
performed at that point in time. Additionally, the PCSs and coaches can lead the first real corrective
action and problem-solving workshop.
STEP 10: LAUNCH MORE ARTS AND VALUE STREAMS

At this point all the different actors will have the necessary experience to carry on with their different
tasks, and the other ARTs can be launched. Since many value streams and many ARTs will enable the
large solution level, the different roles must be defined and people must be assigned to these roles. The
other value streams will also be launched and the various previous steps will need to be performed on
each of them.
STEP 11: EXTEND TO PORTFOLIO

When the ARTs and values streams are successful, the buzz about the new methodology spreads in the
organization and everyone will start adhering to it. This will trigger the need for applying the same
method to the portfolio level. Strategic and governance practices must be aligned with the different
principles of SAFe, with a lean Agile approach of leadership.
STEP 12: SUSTAIN AND IMPROVE

If all the previous steps are successful, the benefits of the new approach should be visible now and the
new way of working should be a part of the company culture. This brings the need for the leaders to
perpetuate the enthusiasm about this new way of working, by developing some activities and also try to
continually improve on the already existing basis.
Jira Implementation
Case Study: Implementing Full SAFe v4.5 in Jira
XYZ Bank implementation of Full SAFe v4.5 in Jira: XYZ bank started its digital transformation four years
ago by adopting the Scrum Framework and Kanban Methodology throughout their organization in all
business units.
Two years ago, the company implemented Scrum and Kanban in a single business unit to simulate an
Agile organization and test whether the methods would be successful if implemented organization wide.
Through this pilot, the company accomplished all the main goals set out by the management board and
decided to fo ahead with the organization wide implementation. Today, the company has already
transitioned all their business and support areas to an Agile methodology, using Kanban and Scrum in
smaller teams, and SAFe at the company-level. Having already implemented and directed the whole
transformation process, the company needed a digital tool to support the SAFe framework as the
management boards at the different levels of the organization struggled to have visibility on the
execution and status of the projects. Jira was already being used at the team level, and was hence
chosen to implement the SAFe framework.
Issue Type Configuration
In order to implement SAFe v4.5 in JIRA, it is important to configure JIRA to be ready to support the SAFe
v4.5 Framework. In order to do so, it’s necessary to create the new issue types that are managed in the
Portfolio (Epic) and in the Large Solution Level (Capabilities). In the Administration section of JIRA, in
particular in the issue section, we can manage and create issue types. The first step is to rename the Epic
JIRA issue type to Feature to represent Features in SAFe, and then create the new issue types Epic and
Capability. While creating the new issue types is advised to give a clear description of the issue and try
to give different icons and colors to them in order to make them more recognizable. To change the icon
for the issue types you should edit it after it has been created (the icon option is not available in the
creation page). Stories, Tasks and Sub-tasks are already created in JIRA we do not need to add anymore
issue types. Plus in Jira are available also Bugs which are described as a problem which impairs or
prevents the functions of the product. Since in SAFe Bugs issue types are not mentioned is up to the
teams to keep it into the possible issue types at the Project Level.
A screenshot of the Issue type section can be seen below.

Hierarchy Level Configuration
After adding and modifying the issue types to prepare the configuration, the hierarchy levels should be
created and mapped to reflect the ones found in SAFe v4.5. This can be done with Portfolio for JIRA in
the Portfolio Hierarchy Configuration section.
Portfolio for JIRA is an extension for the JIRA Software which provides a centralized interface for
managing cross-team requirements, resources, and schedules with a customizable hierarchy. The
installation process for Portfolio for Jira is explained in Appendix C: How to install portfolio for Jira. There
are multiple options to get a license for Portfolio for JIRA. The Cloud version of Portfolio for JIRA where
you pay a $10 monthly flat fee for a maximum of 10 users, and a $3.50 per user/month rate for a
number between 11 and 100 users. For the Self-hosted version of Portfolio for JIRA as the number of
users increase, the price per user ratio decreases ranging from a one-time payment of $10 for 10 users
to a one-time payment of $23,100 for a number of users above 10,001.
In the Portfolio Hierarchy Configuration section, the different JIRA issue type are structured into an
hierarchy which defines the parent/child relationship between the issue types. Therefore, to implement
SAFe into Jira is necessary firstly to create two more levels, that can be named as Epic and Capabilities or
as Portfolio and Large Solution. Once the level is created, Jira allows you to connect a Jira issue type to
Level. Therefore, it’s now necessary to select the two newly created issue types for the top two
hierarchy level (Portfolio-Epic, Large Solution-Capability). The Feature level will automatically connect to
the features since the Jira Epic was previously modified into Features in the Issue type management
section, it is only necessary to edit the name of the level.
JIRA and SAFe Hierarchy
In order to implement SAFe v4.5 with JIRA we need to understand how SAFe functions in an organization
at different levels and what would be the key practices, the activities undertaken and the deliverables
which can be provided
● Portfolio level - At the Portfolio level, the focus is on the generation of ideas which are captured
through an intake funnel. These ideas are then reviewed and analysed for economic and business
viability. Once the Epics have been approved by Portfolio level management, they are then
evaluated at the Large Solution and Program levels.
● Large Solution level - At the Large solution level, the focus is on aligning the direction of large and
complex solutions across multiple ARTs. The Large Solution level facilitates the activities and
artifacts necessary to express functional and nonfunctional requirements to make sure that they
comply with regulations and standards. These Capabilities are assigned to Solution Trains are
created from the Epics to enclose solution deliverables with features.
● Program level - The program team breaks those Capabilities into Features and establishes
dependencies, estimates and bundles them into program Increments or releases. These Features are
assigned to ARTs for and are broken down into Stories for teams at the Team level to handle.
● Team level - At the Team level there is a focus on the development and delivery of planned Feature
functionality which is broken down into Stories and Tasks or Subtasks, and to track these items and
their rollup to the higher-level Features and Capabilities
SAFe v4.5 Portfolio Level Implementation in Jira
To represent the SAFe Portfolio level in Jira, it’s necessary firstly to create a Kanban board to give the
Lean Portfolio Management and Epic Owners visibility on the completion of the Epics. To create the
Portfolio level kanban board you have to select the create board option from the top menu
(Boards-Create New Board) and select the Kanban board as the board type. This procedure will
automatically create a new project into Jira which has to be named Portfolio. Once the board is created,
it’s necessary to configure it to be a Portfolio Kanban Board.
In fact, Custom configuration of the Kanban board is necessary to translate the flow of the SAFe
framework into Jira. And to give the proper tools to the Portfolio Managers.
As previously mentioned, the configuration of the issues types at the portfolio level has been done
according to the SAFe framework and hence allows the Portfolio Management to create and manage
Epics. To create a custom issue type scheme you have to go to the Settings in the issue section, select
issue type schemas and create a new one, selecting only the issue types that you want to be visualized
and managed in that particular Project, hence in the portfolio schema, only the epics are selected.
To mimic the flow in SAFe the epics follow in a custom workflow specifically created and intended for
this (portfolio) organization level. To set up a new workflow it's necessary to access the issues settings
section of the Jira software and go to the workflow section and select “Add workflow”. Once the
software redirects you into the workflow creation interface, you can create custom statuses for your
issues and connecting them to three categories “To Do”, “In Progress”, “Done”. As can be seen from the
workflow above, these categories mark your statuses in different colors, to define the progress of the
project. It's recommended to always create new statuses and not to modify the ones that are already
present in the software, since the editing of an already existing status will change the status in all the
other schemas.
In the Epic issue there is no need to add any custom fields, since is the highest in the hierarchy.
Access control:
In order to limit access to the relevant parties only, roles and restrictions have been configured for user
access to the project portfolio, so that only the users concerned can access and modify the Epics.
According to SAFe the roles that are concerned are:
● Epic Owners: that submit value streams statements to be evaluated and reviewed for approval
● Lean Portfolio Management: provides objective guidance and is in charge of the highest level of
decision-making and financial accountability for the products and Solutions in a SAFe portfolio.
● Enterprise Architect: Drives architectural initiatives for the portfolio.
SAFe v4.5 Large Solution Level Implementation in Jira
To represent the Large solution level in Jira, it’s necessary firstly to create three Kanban boards to give
the Large Solution Management visibility on the completion of the Capabilities (as intended in the new
configuration for Jira) and the allow them to create new issues (Capabilities). To create three kanban
boards in the same project, it’s necessary to initially create the first kanban board that automatically
generates the project, and then enter the project and add the other two in the Boards section inside the
project (on the left side of the screen). Full SAFe v4.5 uses Kanban boards as the tool for visibility at this
level. Custom configuration of the boards is necessary to translate the flow of the SAFe framework into
Jira. The 3 boards to be created are Solution Exploration board, Solution Deployment and Solution
Integration.
The configuration of the issues types has been done according to the SAFe framework and allows the
Large Solution Management to create and manage Capabilities. In order to do that it’s necessary to
create a custom issue schema, as previously did for the Portfolio level. In this project, the only issue type
to be included in the schema is the Capability issue.
this organization level and 3 Kanban Boards are created to show the 3 steps of the continuous delivery
pipeline (Exploration, Integration, Deployment). To set up a new workflow it's necessary to access the
issues settings section of the Jira software and go to the workflow section and select “Add workflow”.
Once the software redirects you into the workflow creation interface, you can create custom statuses
for your issues and connecting them to three categories “To Do”, “In Progress”, “Done”. In this case the
workflow has to take into account all the three boards of the project. Once, the workflow has been
created, the boards column can be renamed to give visibility on the workflow.
The division of the boards is explained in the following image.
Assigning Capabilities to an ART/Solution Train:

In the issue section, the ART and Solution Train label files have been implemented so that the
Capabilities can be assigned to a set of Solution Trains and ARTs, and the filtering allows the user to see
which Solution Trains/ARTs are managing one or multiple Capabilities. The parent issues type option has
been inserted, so that the Capability can be connected to Epic to which it belongs. To add custom fields
it’s necessary to enter the Settings of Jirain the issue section and go to the custom fields. Then, to create
the ART label you need to select “add custom fields” and then select the label field from the standards
custom fields list. The same process can be done to create STs. Once the custom fields are properly
created, in the edit section of the fields it’s possible to select the “screens” (screens are the pages inside
the projects) on which the field will appear, therefore for the arts and solution trains, we selected to
show both label fields in the Program and in the Large Solution Projects.
As, it’s possible to see from the screenshot above, inside the Capability you can now tag the ARTs and
STs and to specify the parent relationship with the Epic.
Moreover, in this level are also defined the PIs for the STs and the features are assigned to the particular
program increment for the selected ST. To create the versions, you need to access the version section
from the icon on the left and once in the page create the version.
Access control:
In order to assign roles and restrictions, user access has been assigned to the Large Solution Level, so
that only the users concerned and access and modify the Capabilities.
● Solution Management: has content authority for the Boards. They are responsible for identifying
Customer needs, prioritizing Features, guiding the work through the different stages.
● The Solution Architect/Engineering: defines a shared technical and architectural vision for the
Solution under development.
● The Solution Train Engineer (STE): facilitates and guide the work of all Solution Trains in the
Value Stream.
SAFe v4.5 Program Level Implementation in Jira
To represent the Program level in Jira, it’s necessary firstly to create three Kanban boards to give the
Program Management visibility on the completion of the Features (as intended in the new configuration
for Jira) and the allow them to create new the issue types (Features). Once again, Full SAFe v4.5 defines
Kanban boards as the primary tool for visibility at the Program Level. Custom configuration of the boards
is necessary to translate the flow of the SAFe framework into Jira. To create the tree boards, it’s
necessary to follow the same process previously done for the Large Solution level.
The configuration of the issues types have been done according to the SAFe framework and allows the
Program Management to create and manage Features.
this organization level and 3 Kanban Boards are are created to show the 3 steps of the continuous
delivery pipeline (Exploration, Integration, Deployment). In this case has been kept the same workflow
of the Large Solution Level and the same board configuration.
Assigning Features to an ART/Solution Train:
As previously for the Large solution level, in the issue section, the ARTs and Solution Trains label files
have been implemented so that the Features can be assigned to a set of Solution Trains and ARTs, and
the filtering allows the user to see which Solution Trains/ARTs are managing one or multiple Features.
The parent issues type option has been inserted, so that the Feature can be connected to the Capability
to which it belongs.
In order to change completely Jira Epics to Features (the field is blocked and required in Jira) is necessary
to access the database of Jira and modify the field (more information is available in the Atlassian
documentation and in the abstract of this document).
Moreover, in this project level are also defined the PIs for the ARTs and the features are assigned to the
particular program increment for the selected ART. To create the versions, you need to access the
version section from the icon on the left and once in the page create the version.
In order to assigning roles and restrictions, has been configured the User access to the project Program,
so that only the users concerned and access and modify the Features.
● Program Management: has content authority for the Boards. They are responsible for identifying
Customer needs, prioritizing Features, guiding the work through the different stages.
● The System Architect/Engineering: defines a shared technical and architectural vision for the
Features under development.
● The Release Train Engineer (STE): facilitates and guide the work of all ARTs in the Value Stream
SAFe v4.5 Team Level Implementation in Jira
At the team level, 10 distinctive team boards have been created (teams can create Scrum, Kanban or
Custom boards), one for every team, to start writing and assigning the user stories per team. No custom
configuration of the boards is necessary to translate the flow of the SAFe framework into Jira. The teams
can select an already pre-configured board or decide to create their own personalized one.
The configuration of the issues types has been done according to the SAFe framework and allows the
Team Management to create and manage the Stories, User Stories, Bugs, Tasks and Sub-Tasks. The issue
type scheme below shows the standard Scrum issue types, as they are predefined in Jira. The team is not
allowed to have visibility on Epics and Capabilities, but has full visibility on the Features.
After the issues are created, they are prioritized, weighted in user story points and broken down into
smaller sub tasks.
In order to assign the stories to the belonging feature it necessary to provide the teams with the
visibility and access to the features. In order to do that the filters in the Team board have to be set so
that the board of each team is shared with the Program level. This allows the Teams to see which
Feature they are developing and, but at the same time doesn’t provide visibility on the work of the
others teams and of the Program level.
Concerning the Workflow and the Fields, each team can select a custom model that best fits their work.
User access:
In order to ensure only relevant parties can access the information, roles and restrictions has been
configured for user access to the Teams’ projects, so that only the users concerned and access and
modify the issues.
● Program Owner: Are responsible for defining Stories and prioritizing the Team Backlog to streamline
the execution of program priorities while maintaining the conceptual and technical integrity of the
Features or components for the team.
● Scrum Master: The servant leaders and coaches for an Agile Team
● Dev Team: The professionals who can develop and test a Story, Feature, or component.
ARTs
The Agile Release Trains are created using the Portfolio for Jira add-on. The Live Plan feature allows the
user, according to the SAFe framework the RTE, to assign a series of releases that can be translated as
PIs in Jira to a series of teams. Therefore by joining the teams that fit into the ARTs and the Program
Boards it’s possible to create a PI plan for the defined ART.
In the picture below, it can be seen that the first increment is set to begin the 13/jun/18 and to finish
the 20/jun/18, while the second is set to start the 20/jun/18 and finish the 27/jun/18 (it has been used a
period of one week for simplify the implementation in this particular case study a PI usually covers 8-12
weeks).
Inside the PI planning can take place also, information about the features that are being developed and
to which PI increment each feature is assigned is available. Further visibility is provided on the single
Stories inside the Features.
As it is mentioned, the Program Increments have been defined as releases in the Program board
therefore in Portfolio it’s possible to have visibility on the development of the PIs.
Each plan (ART - PI Planning) is linked to the respective releases.
Having set up this configuration, the Release Train Engineer can see the status of the projects in terms of
the Agile Release Train, Program Increments, Teams and Sprints as well as the assigned work that each
team is working on.
Solution Trains
The Live Plan feature in Jira Portfolio allows the user, according to the SAFe framework the STE, to assign
a series of releases that can be translated as PI in Jira to a series of teams. Therefore, by joining the
teams that fit into the Solution Trains and the Solution and Program Boards it’s possible to create a PI
plan for the defined ST.
Inside the PI planning is available also information about the features, the capabilities, and the stories
that are being developed and to which PI increment are assigned.
Further visibility is provided by allowing the STE and the Large Solution management to see the teams
that are participating to the ST and their velocity.
As well as the Agile Release Trains, the solution increments have been defined as releases inside the
solution project in Jira.
Structure for JIRA
In order to gain visibility over the whole organization at all levels, it is necessary to use Structure for
JIRA. Structure for JIRA is an extension for the JIRA Software which lets you visualize, track and manage
progress across large-scale projects with adaptable, user-defined issue hierarchies.
There are multiple options to get a license for Structure for JIRA. There is only a Server or Self-hosted
version of Structure for JIRA as the cloud version is not available for that application. The pricing for this
add-on is a one-time payment ranging between $10 and $16,000 depending on the number of users.
The price of $10 is for 10 users while the amount of $16,000 is intended for over 10,000 users.
With Structure for JIRA we can get a full visibility of the whole organization at the Portfolio, Large
Solution, Program and Team levels. This facilitates better understanding of the logical structure of the
organization and the dependencies present at different levels.
The complete structure of this implementation can be found in Appendix H: Full Structure of XYZ Bank
Jira Implementation.
Financial and Burndown Metrics
METRICS WATERFALL METRICS AGILE METRICS
PV Planned Value The value of the work planned to be Budgeted cost of the story points
completed to a point in time, usually the that were scheduled to be
data date, or project completion. completed as of Today: APC * BAC
EV Earned Value The planned value of all the work Budgeted cost for the story points
completed (earned) to a point in time, actually completed as of Today. APC
usually the data date, without * BAC
reference to actual costs.
AC Actual cost The actual cost of all the work Total budget spent to date
completed to a point in time, usually the
data date.
BAC Budget at The value of total planned work, the Total budget for the release
completion project cost baseline.
CV Cost Variance The difference between the value of Difference between planned budget
work completed to a point in time, and actual spend EV - AC
usually the data date, and the actual
costs to the same point in time.
SV Schedule The difference between the work Difference between planned

Variance completed to a point in time, usually the schedule and actual time spent EV -
data date, and the work planned to be PV
completed to the same point in time.
VAC Variance at The estimated difference in cost at the

completion completion of the project.
CPI Cost A CPI of 1.0 means the project is EV / AC

Performance Index exactly on budget, that the work
actually done so far is exactly the
same as the cost so far. Other values
show the percentage of how much
costs are over or under the budgeted
amount for work accomplished
SPI Schedule An SPI of 1.0 means that the project EV/ PV
Performance Index is exactly on schedule, that the work
actually done so far is exactly the
same as the work planned to be
done so far. Other values show the
percentage of how much costs are over
or under the budgeted amount for work
planned.
EAC Estimate At If the CPI is expected to be the same for Based on current state, what the
Completion the remainder of the project total estimated cost of the release
will be at completion, EAC = AC +
ETC
ETC Estimate to Assuming work is proceeding on plan, Based on current state, how much
complete the cost of completing the additional budget is needed to
remaining authorized work complete the release; 1/CPI* (BAC-
EV)
TCPI To Complete Assuming work is proceeding on plan,
Performance Index the cost of completing the
remaining authorized work
Estimated time to Based on the current state, the total
complete estimated time needed to complete
the release 1/SPI * PW
PSP Planned story Total number of story points

points planned for this release
PW Planned weeks Total number of planned

development weeks
AW (actual weeks) Number of development weeks

elapsed to date
CSP Completed Number of story points completed

Story Points to date
PPC Planned AW / PW
Percent Complete
APC Actual CSP / PSP
Percent Complete
Recommendations
Alternative Tool for Implementing Full SAFe v4.5
Due to the current situation of companies trying to increase agility in all levels of the company, the use
of a tool that can facilitate the controlling, monitoring and planning of this situation is indispensable.
Therefore, choosing the right tool can lead to improve the tracking of all the project at each level.
We did a comparison of four tools, three aside from Jira, and compared them against Jira taking into
consideration the aspects required for implementing SAFe. Other aspects such as the user experience or
technical characteristics. Were not taken into account.
Feature
overview
Proprietary / Proprietary, hosted Proprietary / Free Proprietary,

Free trial Commercial
community
License licenses for
open source
and academic
projects
Portfolio None Full support Full support Partial support

planning
Drag-and-drop Full support Full support Full support Full support

Backlog
Management
Task board Yes Yes Yes Yes

view
Iteration burn Yes Yes Yes Yes

down chart
Epics Partial support Full support Partial support Partial support

(hierarchy of
backlog
items)
Release and Partial support Full support Full support Full support
Iteration
Planning and
Tracking
Product None Full support Full support None
Roadmapping
(multiple
releases)
Multiple Full support Full support Full support Full support

products/
projects
Test Partial support Full support Full support Full support

Management
(Acceptance
and
Regression)
Impediment None Full support Full support Full support

tracking
None PO, SM, Team SM, PO, Team None

Member, Member.
User roles Stakeholder, plus
custom roles.
Big community, Robust planning Provides story and Useful features for
multi abilities and feature roll-up for managing agile
–language tracking Epics, enhanced program processes.
support, more Stories and and portfolio
Pros
than 600 Projects management
plugins and Includes
add-ons. integrated defect
management.
Poor backlog, Because of the Requires additional It is desirable to

sprint different features process for linking use other
management which exist inside stories and Microsoft tools
tools this tool, the features to for development
learning curve is higher-level and therefore,
Cons
high to understand portfolio items accomplish a full
all of them. integration with
all the
capabilities this
software offers.
Based on the table above, we believe the best tool for the implementation of SAFe v4.5 is “VersionOne”
because of the different aspects described before.
What is VersionOne?
VersionOne is a software that unifies and enables teams at all levels across the organization to envision
and deliver the best value.
Characteristics
● Agile Portfolio Management
● Reporting & Analytics
● Product Planning
● Product Roadmapping
● Release Planning
● Idea Management
● Sprint Planning
● Test Management
● Tracking
● Collaboration
● Review
● Open Integration Platform
Appendix A: Disadvantages and Risks of a Traditional Organization
Disadvantages
A Traditional organization using the Waterfall methodology comes with specific and very structured
organization that may create some drawbacks and affect the success of the project. Below we will
outline some of the potential issues faced by a traditional organization.
Team Efficiency and Productivity
● In real situations, change is inevitable. Therefore, when the plan is not followed, problems arise
and confusion is created in the team. This can be very demotivating for the team members and
impact their efficiency.
● Traditional organizations use a linear, waterfall approach to project management. This means
that some team members and/or resources will be blocked in proceeding further, if any
preceding tasks have delays. This can be frustrating and result in loss of focus and interests
from the team.
● Every plan is made according to tasks and team members put more effort into handling tasks
than into the quality of the outcome. The work is mainly based on the tasks to be performed
and not on the product. Employees’ sense of responsibility is limited and their skills are only
capitalized to what the job requires and no more. This can kill spontaneity and problem solving.
● Traditional project management leaves little or no room for creativity. Team leaders either focus
excessively on the management processes or set tight deadlines, forcing their staff to work
within strict parameters. This can discourage creative thinking, hamper innovation, and
demotivate the team members.
● Under-utilization of resources is an issue that must be considered when dealing with the
waterfall approach. Let’s consider that project assignments of a software engineer takes 4 out of
5 days of his work week, so he is 80% utilized. Even if he has enough time to do additional work,
he is fully dedicated to the project and this unutilized time of the resource cannot be used.
Requirements understanding
● It is very difficult for a customer or final user to clearly identify all the detailed requirements at
the project start. Since Waterfall requires a SRS (Software Requirements Specification)
document that cannot be changed and the customer is not in contact with the project team, we
may end up delivering a non-relevant product. In the same vein, lot of time is spent by the
developers to understand the client need. The solution architect making the design does not
include the developer team, and misunderstanding can occur in the development phase.
Decision making
● The structure of the organization results in a long decision-making process and can be
demotivating for the team because of the strict organizational hierarchy and specific reporting
lines. In case of many projects in the program or portfolio level happening at the same time,
coordinating the input of multiple managers can require a level of compromise that make the
decision-making process more complex. In addition, you have to be adept at handling the
politics of decision making with many managers so that no one feels their opinion is being
ignored.
Communication
● As directives move through a traditional hierarchy, the message can get distorted. Each
supervisor or manager may interpret your words differently until the message that reaches
employees has little resemblance to what you intended. Even written instructions require
interpretation. The same is true in reverse. If employees raise issues by reporting them to their
immediate supervisors, complaints and suggestions may reach you after several levels of
management. You may get an entirely different picture of what employees were trying to say.
● If the organization has multiple projects, there can be poor communication among them,
causing resources to be duplicated. Communication becomes very important in case of many
project, for resource allocation issues.
Work environment
● Projects have tight schedules and deadlines which makes a stressful workplace, sometimes
leading to under productivity of the team. Some experts have a tendency to complicate
everything, which may confuse your team and cause delays in project delivery.
● Since all the authority is put in the hands of the project manager, no control or authority is made
at the team level to ensure all tasks are well performed. Moreover, the amount of power given
to the project manager can be an issue for members of the team. Since the project manager has
full authority and power over his team members, he can become arrogant.
● Decisions on how the team work is coordinated at a high level by people who do not have a
realistic picture of the work to be performed. This can result in inadaptability of the team.
Cost and resources management
● If the organization has several projects, the resources may be doubled and there may be
miscommunication when it comes to allocating these resources. The company will be hiring
highly skilled individuals and specialized equipment for a short period of time, it will be costly
and the company might spend a lot.
Risks
Complex projects
Project complexity is a continuously growing concern in project environments today. It plays a key role
in the success or failure of project management. This complexity refers to the dynamics of the actual
project rather than the complexity of the project itself. Traditional organizations are ill equipped for this
complexity if they fail to integrate additional measures to control and deal with complexity. This
complexity to which is referred comes from the rise of the digital age, and includes factors such as team
dynamics, remote teams having to work together, risks posed by digitalization and the need for constant
innovation due to the threat of business model disruption by competitors using an innovative way to
capture the markets.
Ambiguity
Traditional organizations attempt to minimize risk subjectivity by monitoring and controlling the impact
of risks on limited scales such as financial. Projects are however becoming increasingly more complex
and this approach does not encompass the multi-criteria of project risks particularly experienced today
in increasingly more complex projects.
Uncertainty
Traditional approaches do not take into account deterministic factors such as uncertainty and variability
when monitoring and controlling projects. Methods to factor these variables in were developed, notably
cost and schedule control indexes, however these are not very widespread in industry due to their
complexity for the required practitioners. Furthermore, uncertainty is increased in the complex-project
driven environment present today.
Propagation
Traditional organizations have very few approaches to facilitate coordination of project organizations, in
particular the interconnection between actors and their activities. These actors generally do not realize
how their actions affect other stakeholders at both the direct and indirect levels.
Chaos
Chaos comes along with the increased complexity of projects and affects especially the efficiency of a
traditional organizations project response plans and decisions on various factors - risks, schedules, and
errors in the initial analysis and planning phases for example.
Appendix B: How to install and configure Jira on a local machine
JIRA Core Installation
1. Go to the website: https://www.atlassian.com/software/jira/download. Select the version to install

and click on the [Download] button.
2. The webpage shows the confirmation of the commencement of the download.
3. When launching the JIRA Software Installer, a window with the wizard installer will appear. Click on
the [Next] button to continue with the installation or [Cancel] to abort the installation.
4. After clicking on the [Next] button, the wizard will allow the user to decide on the type of
installation the user wants to do. The user can choose between the express installation, custom
installation and/or upgrade the existing version of JIRA. Select the option you would like and click on
the [Next] button.
Note: For the purpose of this document, the default installation is the one which is going to be
covered.
5. Because the default installation was chosen, the wizard choses the Installation Directory and the
Home Directory, as well as, the ports where Jira will run. Leave the values as is and click on the
[Install] button.
6. The installation starts.
7. When the installation is done, the wizard will show a message indicating it. Click on the [Next]
button.
8. The wizard will display of the progress of launching Jira.
9. The wizard shows that Jira is accessible via the browser. Click on the [Finish] button.
10. The browser will be launched to set up the JIRA software. Click on the [Set it up for me] option and
on the [Continue to MyAtlassian] button.
11. After that, the user has to set up the license features. For the purpose of this document, installing
Jira on a local machine, the license version chosen was “Jira Software (Server)”. Click on [Generate
License].
12. One 30-day Jira license is generated and the application will ask you to choose the components to
set up the generated license.
13. Jira will require setting up a system administrator. The user needs to fill the form and click on the
button [Next].
14. The Jira configuration starts and the webpage lets know the current status of it.
15. When the configuration is done, the application will show a confirmation and Jira can start to be
used. Click on [Let’s get started].
16. Login with the user account created before and click on the [Log In] button.
17. Choose the language you wish to use in Jira and click on the [Continue] button.
18. (Optional) Jira will show the option to set up an avatar. Once the avatar is chosen, click on the [Next]
button.
19. Finally, Jira is fully configured and ready to use.

Appendix C: How to install and configure portfolio for Jira
The installation of the add-on Portfolio for Jira can follow different paths depending on which Jira
software version is being implemented by the user.
For the cloud version of the software the Portfolio add-on can be downloaded following these simple
five steps:
1. Log into your Jira instance as an admin.

2. Click the admin dropdown and choose Add-ons.
3. Locate Portfolio for Jira in the Atlassian Marketplace
4. Click Free trial (valid for 30 days) or one of the payment options (discussed in Case Study:
Implementing Full SAFe v4.5 in Jira) to download and install your app.
5. Once the add-on is downloaded it will appear on the left menu and it’s ready to be used.
For the server version of Portfolio for Jira, the process is more complicated. Portfolio can be
downloaded and activated by:
2. Click the admin dropdown and choose Atlassian Marketplace.
3. Click Find new add-ons from the left-hand side of the page.
4. Locate Portfolio for Jira via search.
5. Click Try free to begin a new trial (valid for 30 days) or Buy now to purchase a license for
Portfolio for Jira (discussed in Case Study: Implementing Full SAFe v4.5 in Jira).
6. Enter your information and click Generate license when redirected to the website MyAtlassian.
7. Click Apply license.
8. Once the add-on is downloaded and activated it will appear on the top and it’s ready to be
used.
In the case that the add-on, Portfolio for Jira, does not show in the Atlassian Marketplace. It’s possible to
download the add-on manually on the Atlassian Website. In the Jira Portfolio for server homepage (Click
2
here ) the Download option is given at the bottom of the page under ‘Resources’. This will download the
software on your machine in a .obr format.
Once the download has completed, access the “Manage add-ons” section in the Jira software settings
and to Import the add-on by uploading it manually into the system. If this step is done correctly the
installation will automatically begin (the installation my take more than 30 minutes).
Portfolio for Jira is now added to the software but to activate it it’s necessary to generate the license. In
order to successfully create the license, the following steps are required:
1. To go back to the Jira Portfolio for server homepage.
2. Select either “Buy now” or “Try for free”, according to the needs of the users.
3. Enter the account information of the admin of the software.
4. Generate license.
5. Insert the license created in the “Manage add-ons” section in the Jira software settings.
2
https://marketplace.atlassian.com/apps/1212136/portfolio-for-jira?hosting=server&tab=overview
Once the add-on is downloaded and activated, it will appear on the top and it’s ready to be used.
Portfolio has to be used after creating the new issue types, to define the hierarchy and to structure the
ARTs and the STs after creating all the teams and the levels as previously described in this report.
Appendix D: How to install and configure Structure for Jira
To install Structure for Jira there are two possible paths to follow. Structure is only available for the
server version of Jira.
Structure can be downloaded and activated by:
2. Click the admin dropdown and choose Atlassian Marketplace.
3. Click Find new add-ons from the left-hand side of the page.
4. Locate Portfolio for Jira via search.
5. Click Try free to begin a new trial (valid for 30 days) or Buy now to purchase a license for
Structure for Jira (discussed in Case Study: Implementing Full SAFe v4.5 in Jira).
6. Enter your information and click Generate license when redirected to the website MyAtlassian.
7. Click Apply license.
8. Once the add-on is downloaded and activated it will appear on the top and it’s ready to be
used.
In the case that the add-on would not show in the Atlassian Marketplace. It’s possible to
3
download the
add-on manually on the Atlassian Website. In the Jira Structure homepage (Click here ) the Download
option is given at the bottom of the page under ‘Resources’. This will download the software on your
machine in a .obr format.
Once, the download has been completed, it’s necessary to access the “Manage add-ons” section in the
Jira software settings and to Import the add on by uploading it manually into the system, if this step is
done correctly the installation will automatically begin (the installation my take more than 30 minutes).
Structure for Jira is now added to the software but to activate it it’s necessary to generate the license. In
order to successfully create the license, the following steps are required:
1. To go back to the Jira Structure homepage.
2. Select either “Buy now” or “Try for free”, according to the needs of the users.
3. Enter the account information of the admin of the software.
4. Generate license.
5. Insert the license created in the “Manage add-ons” section in the Jira software settings.
Once the add-on is downloaded and activated it will appear on the top and it’s ready to be used.
Appendix E: Potential Issues Installing and Configuring Jira
3
https://marketplace.atlassian.com/apps/34717/structure-for-jira-projects-at-scale?hosting=server&tab=overview
Portfolio Hierarchy and Blocked Fields
To define the hierarchy of an issue type into Portfolio, make sure that the issue type has been
created in your Jira instance. To create a new issue type the steps to follow are:
1. Choose Settings > Issues.

2. Select Issue Types to view all issue types used by your JIRA applications.
3. Select Add Issue Type and enter the following details:
● Name — enter a short phrase that best describes your new issue type
● Description — enter a sentence or two to describe when this issue type should
be used
● Type — specify whether the issue type you are creating is a Standard issue type
or a Sub-Task issue type. Sub-tasks are associated with individual Standard
issues.
2. Select Add to create your new issue type.
To map an issue type in Portfolio you need to follow the steps below:
1. Go to Portfolio > Administration > Portfolio Hierarchy Configuration.

2. Choose the issue types to configure from the drop-down menu and map them into to the
hierarchy level you want, then click Apply.
3. Click Save changes.
4. Now you can work with the new hierarchy levels in the scope view of your plans.
You can create as many hierarchy levels as needed in Portfolio for Jira, it’s recommend you add
new levels of hierarchy above the Epic level. These steps guide the implementation:
1. Go to Portfolio > Administration > Portfolio Hierarchy Configuration and click + Create
Level.
2. Now you can see a list of all the level names and its Jira issue type.
3. Type in the name and map the new level to a Jira issue type.
4. You can remove the level by selecting Remove.
5. Rearrange levels by dragging and dropping the tabs.
The Epic issue type is tied to the Epic hierarchy level in Portfolio for Jira and can't be changed.
The only way to modify the issue is to first rename it in the issue settings as Features and then
modify the blocked fields by:
1. Running the following query via database to determine the JIRA Software custom field
IDs
SELECT id,customfieldtypekey,cfname from customfield where customfieldtypekey like

'com.pyxis.greenhopper.jira%';
2. It should return a result like the following:

id | customfieldtypekey | cfname
-------+--------------------------------------------------------------------+-------------------------
10204 | com.pyxis.greenhopper.jira:gh-global-rank | Rank
10205 | com.pyxis.greenhopper.jira:gh-sprint | Sprint
10206 | com.pyxis.greenhopper.jira:gh-epic-link | Epic Link
10207 | com.pyxis.greenhopper.jira:gh-epic-label | Epic Name
10208 | com.pyxis.greenhopper.jira:gh-epic-status | Epic Status
10209 | com.pyxis.greenhopper.jira:gh-epic-color | Epic Colour
10211 | com.pyxis.greenhopper.jira:greenhopper-releasedmultiversionhistory | Release
Version History
3. You will have to match the id of the field you want to unlock with the according entry in
managedconfigurationitem table's item_id column.
SELECT * from managedconfigurationitem;
id | item_id | item_type | managed | access_level | source | description_key

-------+-------------------+--------------+---------+--------------+----------------------------------------------------+--
--------------------------
10000 | customfield_10204 | CUSTOM_FIELD | true | LOCKED |
com.pyxis.greenhopper.jira:reference-select-locked | gh.customfield.locked.desc
4. You will need to set the managed column to false of any field you want to unlock. For
example, the below will unlock Epic Status and Epic Color:
UPDATE managedconfigurationitem set managed='false' where item_id in

('customfield_11208','customfield_11209');
Note: After the above change the 'access_level' column will remain with the 'LOCKED' value,
but the custom fields will be unlocked from the UI.
5. Make the required changes to the fields.

6. Lock the fields that were unlocked by setting the managed column to true. For example,
the below will lock Epic Status and Epic Color:
UPDATE managedconfigurationitem set managed='true' where item_id in

('customfield_11208','customfield_11209');
Shared Epics
As a standard setting, when the Features are created at in the Program level boards, the team
boards don't have visibility on them. Therefore, in order to assign the stories to the belonging
feature it necessary to provide the teams with the visibility and access to the features. In order
to do that, the Filters in the team boards have to modified in order to include the program level
boards, giving them only the visibility on the Features but not the ability to change or delete the
features. To do so, the steps are:
1. Go to the Project settings.

2. Select the filter section, where is set by default on Private.
3. Change the settings to share with the Program Project.
4. Then, after clicking on Save, in the following page that automatically displays, include
the Program level in the filter.
5. Apply and Save the filter.
Connect the Boards
To connect the boards like it’s required at Program and Portfolio level, it’s necessary to first
define the workflow (can be found in Setting > Workflow) to mimic the evolution of the statuses
of the issues.
Once the workflow is defined and the structure of the board set. To connect the board is just
necessary to repeat the statuses on multiple boards to have visibility on those issues.
Including the hierarchy in the ARTs and STs and how to structure the PIs
One of the main issues of the implementation of SAFe v4.5 in Jira is to implement the ARTs and
solution trains. Portfolio for Jira allows the user to create live plans that can be distributed
across multiple teams, as for a PIs for ARTs and STs. Moreover, Jira allows the user to create
Versions which can be translated in SAFe as PIs, hence in each corresponding level is
necessary to create the PIs for each ART or ST managed. For example, in the Program level,
the following needs to be created for the versions: ART1-PI1, ART2-P1, ART2-P2, etc. Each PI
(version) can be assigned one or multiple Features.
The same process has to be followed at the Large solution level for the ST (assigning the
capabilities to them).
The same process has to be done for the Solution Trains.

Furthermore, once all the PIs for all the ARTs have been defined and inserted in the system, to
create the ART Plan it’s required to:
1. Create a live plan in Portfolio for Jira.

2. add the boards of all the team that are part of the ART
3. add the boards of the Program level
4. select the Features that are to be implemented by the ART
5. select the PIs (versions) that are to be followed by the ART that is being created
6. Deploy the ART into Jira Portfolio and keep track of the work undertaken by each Team
from the Features level up to the Sub-Task level.
Similarly, to create the Solution trains is required to:
1. Create a live plan in Portfolio for Jira.

2. Add the boards of all the team that are part of the ST.
3. Add the boards of the Program level ( to have visibility on the level above and the
features that are being implemented)
4. Add the boards of the Large Solution level.
5. Select the Capabilities that are to be implemented by the ST (the Features and all the
issue levels below will be automatically selected).
6. Select the PIs (versions) that are to be followed by the ST that is being created.
7. Deploy the ST into Jira Portfolio and keep track of the work undertaken by each Team
from the Capabilities level up to the Sub-Task level.
Appendix F: Steps to implement Full SAFe v4.5 in Jira
Appendix G: Full Structure of XYZ Bank Jira Implementation
View publication stats
References
Atlassian, 2018. Atlassian. [Online]

Available at: https://fr.atlassian.com/software/jira/agile
[Accessed June 2018].
CollabNet, 2018. CollabNet. [Online]

Available at: https://www.collab.net/
DataArt, 2015. DataArt. [ Online]

Available at: https://blog.dataart.com/top-five-agile-management-tools/
Kanbanize, 2018. Kanbanize. [Online]

Available at: https://kanbanize.com/kanban-resources/getting-started/what-is-kanban/
Leffingwell, D., n.d. SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises. 2nd ed.
s.l.:s.n.
Merkhofer, M. W., 2018. Lee Merkhofer Consulting. [Online]

Available at: http://www.prioritysystem.com/implementingppm2.html
ilan, Italy, PA: Project

Omar, Z., 2010. Roles, responsibilities, and skills in program management. M
Management Institute.
Scaled Agile, Inc, 2018. Scaled Agile. [ Online]

Available at: https://www.scaledagileframework.com/
Scrum.org, 2018. Scrum.org. [ Online]

Available at: https://www.scrum.org/resources/what-is-scrum
VersionOne, Inc, 2018. VersionOne. [ Online]

Available at: https://www.versionone.com/what-is-kanban/

SAFe 4.5 + JIRA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAFe 4.5 + JIRA

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

FULL SAFE V4.5 IMPLEMENTATION IN JIRA

Preprint · January 2018

The user has requested enhancement of the downloaded file.

Overview of a Traditional Organization 4

The phases that make up

Introduction to Scrum Methodology

SAFe Roles Mapped to a Traditional Organization

SAFe Team Level Roles:

Traditional project management roles:

Traditional Roles SAFe Roles

Project Manager (Scope) and Product Owner and Sponsor

Project Manager (Admin) Scrum Master and Product

Development Team Development Team

Project Team Agile Team

Project Management Office No equivalent SAFe role

SAFe Roles Mapped to a Traditional Organization

SAFe Program Level Roles:

Traditional project management roles:

Program Manager Release Train Engineer

No equivalent traditional role System Architect/Engineer

Business Change Manager No equivalent SAFe role

Program Management Office and Product Manager

Large Solution Level

SAFe Roles Mapped to a Traditional Organization

SAFe Program Level Roles:

Traditional Organization Roles:

SAFe Program Level Roles:

Traditional Organization Roles:

Portfolio Manager Lean Portfolio Manager (LPM) and Epic

Program Managers No equivalent role

Project Managers No equivalent role

Resource Managers No equivalent role

No equivalent role Enterprise Architect

Roadmap: How to transition from a Traditional to Agile Organization by

STEP 1: REACHING THE TIPPING POINT

STEP 2: TRAIN LEAN AGILE CHANGE AGENTS

STEP 3: TRAIN EXECUTIVES, LEADERS AND MANAGERS

STEP 5: IDENTIFY THE ARTS AND VALUE STREAMS

STEP 6: CREATE THE IMPLEMENTATION PLAN

STEP 7: PREPARE FOR THE ART LAUNCH

STEP 8: TRAIN TEAMS AND LAUNCH THE ART

STEP 9: COACH ART EXECUTION

STEP 10: LAUNCH MORE ARTS AND VALUE STREAMS

STEP 11: EXTEND TO PORTFOLIO

STEP 12: SUSTAIN AND IMPROVE

Issue Type Configuration

A screenshot of the Issue type section can be seen below.

According to SAFe the roles that are concerned are:

Assigning Capabilities to an ART/Solution Train:

According to SAFe the roles that are concerned are:

SAFe v4.5 Program Level Implementation in Jira

According to SAFe the roles that are concerned are:

According to SAFe the roles that are concerned are:

Each plan (ART - PI Planning) is linked to the respective releases.

METRICS WATERFALL METRICS AGILE METRICS

SV Schedule The difference between the work Difference between planned

VAC Variance at The estimated difference in cost at the

CPI Cost A CPI of 1.0 means the project is EV / AC

PSP Planned story Total number of story points

PW Planned weeks Total number of planned

AW (actual weeks) Number of development weeks

CSP Completed Number of story points completed

Proprietary / Proprietary, hosted Proprietary / Free Proprietary,

1. Go to the website: https://www.atlassian.com/software/jira/download. Select the version to install

Atlassian, 2018. Atlassian. [Online]

CollabNet, 2018. CollabNet. [Online]

DataArt, 2015. DataArt. [ Online]

Kanbanize, 2018. Kanbanize. [Online]

Merkhofer, M. W., 2018. Lee Merkhofer Consulting. [Online]

ilan, Italy, PA: Project

Scaled Agile, Inc, 2018. Scaled Agile. [ Online]

Scrum.org, 2018. Scrum.org. [ Online]

VersionOne, Inc, 2018. VersionOne. [ Online]