After a project is over, it is important that the Scrum team and the
stakeholders look back and discuss the lessons learnt during the course
of the project. This in itself is a process, called the Retrospect
project, which comes right after the deliverables are shipped.
The Release phase emphasizes delivering the Accepted Deliverables to the
customer and identifying, documenting, and internalizing the lessons
learned during the project. In the Retrospect Project process, which
completes the project, organizational stakeholders and Scrum Core Team
members assemble to retrospect the project and identify, document, and
internalize the lessons learned. Often, these lessons lead to the
documentation of Agreed Actionable Improvements, to be implemented in
future projects.
Inputs
Scrum Core Team(s)
Chief Scrum Master
Chief Product Owner
Stakeholder(s)
Scrum Guidance Body Recommendations
In Retrospect Project process, Scrum Guidance Body
Recommendations can include a repository of internal templates that
support the future projects, and guidance for conducting the Retrospect
Project Meeting. The guidance provided can relate to administrative
procedures, audits, evaluations, and project transition criteria. Often,
they also include how the organization will maintain the knowledge base
of lessons learned and information from all projects.
Tools
Retrospect Project Meeting*
The Retrospect Project Meeting is a meeting to determine ways in
which team collaboration and effectiveness can be improved in future
projects. Positives, negatives, and potential opportunities for
improvement are also discussed. This meeting is not Time-boxed and may
be conducted in person or in a virtual format. Attendees include the
Project Team, Chief Scrum Master, Chief Product Owner, and
Stakeholder(s). During the meeting, lessons learned are documented and
participants look for opportunities to improve processes and address
inefficiencies.
Other Tools for Retrospect Project
Some of the tools used in the Retrospect Sprint process can also be used in this process. Examples include:
- Explorer — Shopper — Vacationer — Prisoner (ESVP) exercise
- Speed Boat
- Metrics and Measuring Techniques
Scrum Guidance Body Expertise
In Retrospect Project process, the primary responsibility of
the Scrum Guidance Body is to ensure that the lessons learned in each
project are not lost and are embedded in the organization. Also, there
may be suggestions in the Scrum Guidance Body Recommendations concerning
how the Retrospect Project meeting should be conducted.
Outputs
Agreed Actionable Improvements
Agreed Actionable Improvements are the primary output of the Retrospect Sprint
process. They are the list of actionable items that the team has come
up with to address problems and improve processes in order to enhance
their performance in future Sprints.
Assigned Action Items and Due Dates
Once the Agreed Actionable Improvements have been elaborated and
refined, action items to implement the improvements may be considered by
the Scrum Team. Each action item will have a defined due date for
completion.
Proposed Non-functional Items for Program Product Backlog and Prioritized Product Backlog
When the initial Prioritized Product Backlog is developed, it is
based on User Stories and required functionalities. Often,
non-functional requirements may not be fully defined in the early stages
of the project and can surface during the Sprint Review or Retrospect
Sprint Meetings. These items should be added to the Prioritized Product
Backlog as they are discovered. Some examples of non-functional
requirements are response times, capacity limitations, and security
related issues.
Updated Scrum Guidance Body Recommendations
The self-organizing and empowered Scrum Team is expected to learn
from any mistakes made during a Sprint – and these lessons learned help
the teams improve their performance in future Sprints.. These lessons
learned may also be documented in Scrum Governance Board Recommendations
to be shared with other Scrum teams.
We know that a Scrum project involves a collaborative effort to
create a new product, service, or any other result. So we need to
define, how the methodology works for a project, program or portfolio.
But before that, we need to define these three terms.
Definition of Project, Program, and Portfolio
- Project—A project is a collaborative enterprise to either create new
products or services or to deliver results as defined in the Project
Vision Statement. Projects are usually impacted by constraints of time,
cost, scope, quality, people and organizational capabilities. The
objective of project team is to Create Deliverables as defined in
Prioritized Product Backlog.
- Program—A program is a group of related projects, with the objective
to deliver business outcomes as defined in the Program Vision
Statement. The Prioritized Program Backlog incorporates the Prioritized
Product Backlogs for all the projects in the program.
- Portfolio—A portfolio is a group of related programs, with the
objective to deliver business outcomes as defined in the Portfolio
Vision Statement. The Prioritized Portfolio Backlog incorporates the
Prioritized Program Backlogs for all the projects in the program.
Scrum in Projects
Since Scrum favors small teams, one may think that this method can
only be used on small projects, but this is not the case. Scrum can also
be used effectively on large-scale projects. When more than ten people
are required to carry out the work, multiple Scrum Teams may be formed.
The project team consists of multiple Scrum Teams working together to
Create Deliverables and Product Releases, so as to achieve outcomes
desired for the overall project.
Since a project can have multiple Scrum Teams working in parallel,
coordination between different teams becomes important. The Scrum Teams
usually communicate and coordinate with each other in a variety of ways,
but the most common approach is known as a Scrum of Scrums (SoS).
Members representing each Scrum Team come together to discuss progress
and issues and to coordinate activities between teams. These meetings
are similar in format to the Daily Standup Meetings; however, the
frequency of the Scrum of Scrums could be pre-determined intervals or
they could be coordinated as required by the different Scrum Teams.
Scrum of Scrums (SoS) Meeting
A Scrum of Scrums Meeting is an important element when scaling Scrum
to large projects. Typically, there is one representative in the meeting
from each Scrum Team—usually the Scrum Master—but it is also common for
anyone from the Scrum Team to attend the meeting if required. This
meeting is usually facilitated by the Chief Scrum Master and is intended
to focus on areas of coordination and integration between the different
Scrum Teams. This meeting is conducted at pre-determined intervals or
when required by the Scrum Teams.
In organizations that have several Scrum projects happening
simultaneously, the Scrum of Scrums meeting can be scaled up another
level to what is referred to as a Scrum of Scrum of Scrums meeting. In
this situation, a separate Scrum of Scrums Meeting is held to coordinate
each group of projects that are directly related to each other.
In this example, there are six projects taking place simultaneously.
Three of the projects are directly related to each other: projects A, B,
and C. The other three that are directly related to each other are
projects D, E, and F. A Scrum of Scrums meeting is held to coordinate
the interdependencies between the projects in each directly related
group. Then a Scrum of Scrums of Scrums Meeting is conducted to
coordinate and manage the activities of all projects.
Scrum in Programs and Portfolios
Programs
In programs, important roles to manage Scrum programs are:
Program Product Owner—Defines the strategic objectives and priorities for the program
Program Scrum Master—Solves problems, removes impediments, facilitates, and conducts meetings for the program
These roles are similar to those of the Product Owner and Scrum
Master except they meet the needs of their program or business unit
rather than those of a single Scrum Team.
Portfolios
Similarly, in portfolios, important roles to manage Scrum portfolios are:
Portfolio Product Owner—Defines the strategic objectives and priorities for the portfolio
Portfolio Scrum Master—Solves problems, removes impediments, facilitates, and conducts meetings for the portfolio
The needs and structure of each organization are different. It is the
responsibility of the Scrum Guidance Body to scrutinize the
organization at different levels to understand and define appropriate
application of Scrum and to act as a consulting body for everyone
working on a project, program, or portfolio.
Working with Program and Portfolio Team
When applying Scrum to manage projects within the context of a
program or portfolio, it is strongly recommended that the general
principles of Scrum presented in this publication are adhered to. It is
understood though, that in order to accommodate the overall program or
portfolio activities and interdependencies, minor adjustments to the set
of tools, as well as the organizational structure may be required.
Portfolios and programs have separate teams with different sets of
objectives. Program management teams aim to deliver capabilities and
realize certain goals that contribute toward the achievement of specific
program objectives. In contrast, the portfolio team has to balance the
objectives of various programs to achieve the strategic objectives of
the organization as a whole.
Managing Communication with Program and Portfolio Teams
The problems and issues faced when using Scrum within a program or
portfolio primarily involve coordination across numerous teams. This can
lead to failure if not carefully managed. Tools used for communication
need to be scaled to match the requirements of the many teams involved
in a program or portfolio. Each Scrum Team must address not only
internal communications, but also external communications with other
teams and the relevant stakeholders of the program or portfolio.
Maintaining Stakeholder Involvement
Scrum requires complete support from the project stakeholders. The
responsibility for keeping stakeholders engaged lies with the Product
Owner. The following are actions recommended for maintaining stakeholder
engagement and support:
- Ensure effective collaboration and stakeholder involvement in the project
- Continually assess business impact
- Maintain regular communication with stakeholders
- Manage stakeholders’ expectations
One key stakeholder is the sponsor—the individual who provides the
funds and other resources for a project. Sponsors want to understand the
financial bottom line related to a product or service and are typically
more concerned with final outcomes rather than with individual tasks.
It is important that the sponsors who are funding the project have clarity on the following issues:
- Benefits of implementing Scrum
- Target deadlines and estimated costs of Scrum project
- Overall risks involved in Scrum projects and the steps to mitigate them
- Expected release dates and final Deliverables
Acknowledgement: This content is the copyright of www.scrumstudy.com
Original url: http://www.scrumstudy.com/blog/scrum-methodology-in-projects-programs-and-portfolios/
The Scrum framework is driven by the goal of delivering maximum
business value in a minimum time span. One of the most effective tools
for delivering the greatest value in the shortest amount of time is
prioritization.
Prioritization can be defined as “Determination of the order and
separation of what must be done now, from what needs to be done later”.
The concept of prioritization is not new to project management. The
traditional Waterfall model of project management proposes using
multiple task prioritization tools. From the Project Manager’s point of
view, prioritization is integral because certain tasks must be
accomplished first to expedite the development process and achieve the
project goals.
Some of the traditional techniques of task prioritization include
setting deadlines for delegated tasks and using prioritization matrices.
Scrum uses Value-based Prioritization as one of the core principles
that drives the structure and functionality of the entire Scrum
framework—it helps projects benefit through adaptability and iterative
development of the product or service.
More significantly, Scrum aims at delivering a valuable product or
service to the customer on an early and continuous basis. Prioritization
is done by the Product Owner when he or she prioritizes User Stories in
the Prioritized Product Backlog. The Prioritized Product Backlog
contains a list of all the requirements needed to bring the project to
fruition.
Once the Product Owner has received the business requirements from
the customer and written these down in the form of workable User
Stories, he or she works with the customer and sponsor to understand
which business requirements provide maximum business value.
The Product Owner must understand what the customer wants and values
in order to arrange the Prioritized Product Backlog Items (User Stories)
by relative importance.
Prioritization results in deliverables that satisfies the
requirements of the customer with the objective of delivering the
maximum business value in the least amount of time.
For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog