Monday, January 17, 2022

ACP Live Lessons Success Story: ACP Live Lessons is the Best Way to Earn Your PMI-ACP Credential

 By Sindhu Pillai, PMI-ACP, PMP



Introduction

One year ago, I attended an interview and the interviewer asked me a large number of questions on Agile methodologies. I couldn’t even answer a single question properly. 

I took it very personally and felt very offended by it. I made up my mind to master this topic and decided to earn the PMI-ACP credential. 

At the end of my journey, I’ve not only earned the ACP certification, but also understand the Agile mindset and I want to pursue this understanding in my career path.


ACP 21 Contact Hours Experience

I bought Satya's PMI-ACP Book and PMI-ACP Live Video Lessons because I believe in the guarantee he claims. Both the video course and the book have helped me crack the ACP exam. In fact, I was sure that I would crack the ACP exam with Satya’s help. 

After going through all domains, I wrote a test conducted by Satya (as a part of ACP Live Lessons, FAQs). After completing the test, I received the needed 21 contract hours to fill the ACP exam application form.

Own Study

I first bought Satya’s course material (bought both the book and video course) to kick-start my preparation. However, I couldn’t stick to a regular routine of keeping in touch with the course as my official workload increased. I also had a few family emergencies because of which I had a gap in my studies and was finding it very difficult to get back on track. 

When I took PMP training from Satya, I remember his words: “Everyone is enjoying their weekends. But you are sitting here and attending classes. MAKE IT COUNT”.  I kept telling myself, “make it count Sindhu for the weekends and hours you have already put in by sacrificing all the weekend time.” 

I did put my heart and soul into preparation and went hard during December 2021, when the workload reduced. In this month and previous one, I could invest up to 8 hrs a day in preparation. 

Preparation and practice of questions will be the keys and there is no shortcut to success! I’ve gone through Satya’s Live Lessons course a couple of times till my concepts were clear. Simultaneously, I made my notes, which I could refer to whenever needed. And I did a lot of Mock Questions, which were provided by him. 

I did have my ups and downs during the preparation. Satya was always available to help me with all queries and guide me through any obstacle I came across.

Review – PMI-ACP Live Lessons

The ACP Live Lessons course comes with a money back guarantee with no conditions applied, except you appearing in the exam. I was very certain that this course is a complete package to earn this certification. Also, I’ve already used Satya’s PMP Live Lessons, which helped me to clear the PMP exam. Hence, I didn’t have any second thoughts before getting the Live lessons and the I Want To Be An ACP book from Satya. 

The ACP Live Lesson course covers every possible aspect of Agile and associated concepts. Satya has created short and long videos and broken down the lessons in such a way that it makes our life easier. At certain points Satya asks a few questions which act like revisions automatically. There are a set of Smart Card questions after every domain which ensures you have the fundamentals in place. 

After every domain there are a good number of mock questions provided. This helps you to gauge your understanding with respect to the specific domain. Once you are done preparing with all the domains, there are lessons available with video exercises which gauges your overall understanding of this course. 

I found this course very helpful in understanding the Agile principles, values, methodologies in a very insightful way.

After you are done with all the domains and practice tests provided at the end of the individual lessons, there are six full-length questions sets provided in this course. These question sets get tougher with each set. 

These question sets will train to face the exam questions where you get 180 minutes to appear 120 questions. My score was consistently above 95 to 100. Satya informed me these scores are good.

Finally, in my ACP exam, I was able to score Above Target in five domains and Target in two domains. This I did in a few months after the knowledge I gained using this course material and by doing 6 full length questions provided by Satya.

ACP Exam Experience

I booked a centre close to my house to avoid longer travel in traffic. I visited the exam centre a day prior to the exam and enquired about the documents required on the day of exam. The full-length mock questions had given me a feel of the actual exam. The more seriously you take it, the easier it will be for you in the exam.

Following are highlights from my ACP Exam:

  • In the ACP exam I faced a lot of questions on Scrum, Retrospectives, Kanban and Velocity. 
  • There are not many mathematical questions. I had faced one on Velocity.
  • The exam follows the domain distribution closely. The better prepared you are, the higher chances of you clearing the exam.
  • During the exam, keep a tab on timing and ensure you don’t spend much time on a single question. There is an option to flag the question which can be reviewed later. 
  • There is an inbuilt calculator hence you don’t have to carry a calculator.

Suggestions for ACP Aspirants

Dos: 

  • Always stay focused and always stay in touch with the course during preparation. 
  • Do a lot of practice questions and revisit the areas where you go wrong.
  • Pay special attention to topics where Satya says: it’s important. 
  • I did prepare thoroughly on Scrum, Kanban, Velocity, Charts, XP, Retrospective and I did get a lot of questions in my exam related to them.
  • I’ve always visualized myself clearing the exam and returning home with a pack of sweets and that did happen, so it’s important to stay positive.

Don’ts:

  • You should always remember that by failing to prepare you are preparing to fail!! Hence, leave no stones unturned when you prepare. Success will follow you.

Conclusion

Sindhu Pillai, PMP, PMI-ACP

I’m currently working as a Project Manager in Kyndryl (previously IBM). Now I would like to work in an Agile Environment and use the knowledge & skills earned with this course and the ACP credential.


More on ACP Live Lessons - Guaranteed Pass:

ACP 21 Contact Hours Course:

Wednesday, January 12, 2022

The Value of an Agile Project Management Office in 2020s


Imagine this scenario as you start-off your day: You open your business site and the message says: “it doesn’t exist.” You then try to login to your email account, which also displays the same message. Your heartbeat goes up and you rub your eyes in disbelief. You remember receiving emails from customers about payments via payment apps, but there too, the same message is displayed, “this account doesn’t exist!” Overall, you feel like the character of the 1998 movie, Enemy of the State.

Is my imagination running wild? Not really.

Such a scenario happened to many in mid-December 2020. A number of service providers’ sites and applications were hacked and systems were brought down. In fact, I thought my personal computer had been hacked, and I rebooted a couple of times without knowing what exactly to do because my service providers’ status dashboards were all green–a good 10 minutes into the internet outage.

Now imagine that a senior executive starts off his day and decides first to have a quick look at the project dashboard expecting to see metrics such as the current status of projects, earned value indices in terms of money and performances, and top risks. Instead, he sees story boards, iteration and release burndown charts, and velocity graphs. Can you feel the frustration, confusion, and possibly anger? What could have been done differently?

Welcome to the concept of the Project Management Office or PMO.

In this article, we will learn about PMOs as organizational structures, about various types of PMOs, and about traditional roles within a PMO. Then, we will dive into the topic of Agile PMO, its relevance, and a number of roles that can be played by such a PMO.

PMO Definition

Any organization exists primarily to provide business value to its stakeholders–internal or external. A PMO, like the service providers I mentioned in the example at the beginning of this article, also exists to provide value and insight into project performances.

The Project Management Institute (PMI) provides a broad definition of PMO as:

A project management office (PMO) is an organizational structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques. 

As noted in the definition, a PMO is an organizational structure. If it exists, then a number of Project Managers (PMs) can be a part with various roles and responsibilities.

Do note that the “P” in PMO can stand for a project, program, or portfolio, and the “O” can refer to the organization itself.

With a standardized set of processes, practices, and metrics, enabled by a PMO, the executive stakeholder would not have faced the “it does not exist” situation as previously mentioned.

Types of PMOs

As per PMI, there are three types of PMOs:

  • A Supportive PMO largely plays a consultative role such as providing templates, imparting training and coaching, and storing lessons learned across projects.
  • A Controlling PMO plays a role in project compliance to standards and/or regulations, and it ensures conformance with various governances and associated frameworks. It can also be involved in audits of projects and project works.
  • A Directive PMO exerts highest power and has the ability to initiate and/or terminate projects in an organization. You can say, this PMO directly manages all of an organization’s projects.

While the degree of control provided by the supportive PMO will be low, controlling and directive PMOs will have moderate and high degrees of control, respectively.

Traditional Roles of PMO

If a PMO structure exists in an organization, then the main role in a traditional set-up is to support the PMs. Beyond that, the PMO holds some or all of these listed responsibilities:

  • Standardization: Standardization of processes, policies, procedures, templates, and other documentation, along with compliance.
  • Knowledge sharing and retention: Acting as a repository of lessons-learned and providing access to projects as and when needed.
  • Training: Facilitating or conducting, providing coaching, and mentoring.
  • Consulting: Adopting various project management frameworks or methods.
  • Resourcing: Managing shared resources across projects.
  • Communication: Coordination communication across various projects.

For a PMO, unlike a program or portfolio, it’s not necessary that the projects are related or managed as a collection.

With this background, let’s proceed towards the concept of Agile PMO. The first question that comes to mind in having a PMO coupled with an Agile approach is this:

Is a PMO really needed at all in an Agile setting? Are not Agile teams cross-functional, self-organizing, and self-managing?Isn’t there a leader who serves the team and removes the impediments?

At first-glance, having an Agile PMO may look contradictory–not only to the way Agile teams operate, but also to Agile values and principles. However, it need not be the case.

As noted in the definition, a PMO is an organizational structure. Your organization may or may not have such a PMOstructure, but if your organization does and your organization is transforming itself to adopt Agile practices, then it must change to have an Agile PMO because agile creates structural, as well as mindset changes.

Agile PMO

Instead of a traditional directing or commanding/controlling PMO which first dictates and enforces standards, policies, procedures, an Agile PMO is more facilitative in nature. An Agile PMO takes the most effective practices used in other projects and shares them across the organization. An Agile PMO is useful when an organization is doing a transition to an Agile approach, and particularly can play a crucial role if the organization is planning to undergo an Agile transformation.

In the context of Agile, PMOs will have the characteristics shown in the below figure:


Let’s break these down one at a time.

Value-Driven

This is the most important aspect of an Agile PMO. The PMO’s goal should be to deliver the right value. An agile PMO should have a customer collaboration mindset. Customers, in this case, are the internal customers within the organization and can also be external customers. In many cases, this may result in PMOs working as a “consulting business unit” in an organization. The PMO can tailor their work to meet the customer’s need. For example, the PMO is responsible for providing the template for use story or the template for Product Review/Demonstration.

Multi-Disciplinary

An Agile PMO should have competencies other than project management, e.g., organization design, change management etc.

Center-of-Excellence (CoE)

With a plethora of Agile frameworks available, it’s easy to get lost in the woods. An Agile PMO deeply understands a variety of approaches available and can adopt or tailor the ones that best meets the organizational needs.

Change-Agent

An organization usually struggles while transforming to fully adopt Agile values, principles, and practices. It’s never easy to move into a different mindset and way of working. An Agile PMO acts as a change-agent and guide.

Invitation-Oriented

An Agile PMO invites for its services only the projects or project teams which are interested in PMO services. This kind engagement ensures that the practices are followed vs. a PMO forcing its practices on teams. 

Roles Played by Agile PMO

Let’s consider some of the roles played and responsibilities that can be taken-up by an Agile PMO. There are many applicable roles here, and I’ve highlighted a few of them in the below figure.

Let’s consider them one by one.

Multi-project Management

Whereas the Agile project manager is the obstacle remover for the team, many times an Agile PMO overlooking a number of projects is an obstacle remover for the program (defined as a collection of interrelated projects, sub-programs, and other works).

At the level of a portfolio, which is a collection of programs, projects, sub-portfolios, and operations, the PMO can work on investment themes, i.e., which project to take on or invest in.

Stakeholder Engagement

In the beginning stages of an Agile transformation, it’s highly likely that there will be resistances to the changes being brought in. The PMO, in this case, informs, communicates, educates, and gets buy-in from the stakeholders having Agile mindset, values, and principles.

Simultaneously, when a trial project is undertaken by an Agile PMO, the team members may not get the needed support from stakeholders across the organization. Here, too, an Agile PMO can help provide training to existing or aspiring POs, SMs, Agile PMs, and team members.

Standard Development and Implementation

Earlier we saw the roles played by PMOs in a traditional set-up. In the context of Agile, the PMO can provide:

If different teams have different metrics, it doesn’t help the organization at all. Sometimes, teams may even inflate data to show they have done more than planned. An Agile PMO helps to standardize on meaningful metrics such as release burndown, cycle time, etc.

Compliance and Audit

An Agile PMO can act as the informant on compliance issues and/or amplify the teams’ external department needs regarding compliance. The Agile PMO, in this case, should try to be facilitative, i.e., listen to what is working for the team instead of dictating or directing.

If it’s regulatory compliance, then the PMO can find ways to get it done, e.g., putting it as a backlogged item in the Product Backlog in collaboration with the Product Owner (PO).

The Agile PMO, like its traditional counterpart, can participate in audits, which is basically to see if project activities comply with organizational, as well as project policies, processes, and procedures. An example is participation in Quality Audit.

Resourcing

In any organization, there will be critical resources, which are shared across Agile teams, e.g., architects, database administrators (DBAs), technical writers, etc. Sometimes, non-human resources have to be procured from outside, and these are used on a shared basis. An Agile PMO can work with the POs, Agile PMs, Scrum Masters (SMs), and Functional Heads to satisfy the need of such resources.

The Agile PMO can also help in hiring resources and evaluating team members. An example is developing interview guidelines for Agile practitioners.

Training, Coaching, and Mentoring

Here the Agile PMO can act as a coach, trainer, and educator by themselves or by partnering (or coordinating) with the training unit of the organization or external training organization.

The Agile PMO can conduct sessions on:

Strategic Focus and Alignment

In an Agile PMO setting, the product backlog is executed over a number of iterations or with a flow-based cadence in order to move towards the vision or goal of the product. This, in turn, is usually linked with the strategic objectives, mission, and vision of an organization.

However, a large organization can have many initiatives with hundreds (or thousands) of projects running. In such cases, it’s possible to miss the strategic alignment for all projects in the organization. The Agile PMO defines and ensures a strategy deployment method.

In addition, an Agile PMO can also have additional roles such as that of a traditional PMO—facilitating learning by storing, managing, and dispensing lessons learned from various retrospectives. 

Conclusion

In the beginning of this article, I raised the question, Do we really need Agile PMO when Agile teams are self-managing and cross-functional? 

Over the course of this article, we discussed various utilities of having such an organizational structure. However, if it’s a small organization, if the owner of the organization is driving few projects on his or her own, or if there are dedicated departments for compliance, audit, training etc., then an Agile PMO may not be needed.

Nevertheless, for a large organization that requires a complete Agile transformation and/or has a large number of projects running, the Agile PMO structure will bring a number of benefits and business value. 

--

This article was first published by MPUG.com on 2nd February, 2021. 


References

[1] Book: I Want To Be An ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[2] Book: I Want To Be A PMP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[3] The Project Management Body of Knowledge (PMBOK), Combo 6th Edition, by Project Management Institute



Thursday, January 06, 2022

A Deeper Look: Top Changes in the New 2020 Scrum Guide for Agile Practitioners


A new version of Scrum guide was released in November, 2020. There are quite a few changes in the guide, as well as new additions. While the outline and structure of the guide have remained almost the same, as you go through the guide, you will immediately notice three high-level changes:

  • The new guide is a much lighter and smaller version.
  • It’s less prescriptive and seems to be intended for a wider audience group, particularly non-software users.
  • It contains commitments for each of the Scrum artifacts.

In this article, I’ll outline the top changes and the deeper meaning associated with each change. My perspective is based on my analysis, my own interpretations, and the interactions I’ve had with Agile practitioners who follow my publications, books, and/or courses. 

Product Goal

The Product Goal has been defined clearly. It’s not an introduction because it existed earlier, but in the previous version, it was mentioned along with the vision.  

As per the guide, the Product Goal is the future state of the product. This definition of the ‘goal’ can create confusion for many who understand project-program-portfolio management and how goals aligns with the vision, mission, strategy, and objectives of an organization.

Ideally, the vision is the future of a product or program/portfolio or an organization. A vision is always associated with goals, without which a vision has no value or meaning.

However, as you look closely at the new guide, a big picture emerges:

  • The Product Goal is the long-term objective of the team.
  • A team works on and fulfills a single objective at a time.
  • Before tackling another objective, the team has to fulfill (or abandon) the objective they are currently working on.

In other words, the goal is written with one or more objectives for the team. As the product roadmap is prepared, it gives further directional clarity to the product goal. The product goal should be linked to the strategic goals of the organization. One could summarize this by saying:

  • The Product Goal is more strategic in nature, whereas,
  • Sprint(s), mentioned as a project in the guide, will be tactical in nature.
  • With each Sprint (iteration), the product moves closer to the product goal.

The Product Owner (PO) is the person who is responsible in building, and clearly communicating product goal to the team. The items in the product backlog (PBIs) should map to the Product Goal. Product Goal also reflects one of the values of Scrum: “Focus.” The team, as earlier noted, should focus on one objective at a time.

Now, you may be wondering what happens when multiple teams are working on the product backlog?

Regardless of the number of teams, there will be a single product backlog, a single PO, and a single product goal. This is depicted in the figure below.

 

Commitment based Artifacts

Now, every artifact in Scrum comes with a commitment.

The formal artifacts in Scrum are three:

  • Product Backlog
  • Sprint Backlog
  • Increment

Now, all these artifacts come with commitments to ensure transparency and progress.

  • For Product Backlog, the commitment is the Product Goal.
  • For Sprint Backlog, the commitment is the Sprint Goal.
  • For Increment, the commitment is the Definition of Done (DoD).

While Product Goal is newly introduced, Sprint Goal and DoD (earlier called “done”) existed earlier. In the new guide, all of these have found homes. For example, the home of Product Goal is the Product Backlog. 

At this point, it may be useful to note that “Commitment’ is also one of the values of Scrum, others being Focus, Openness, Respect, and Courage. Hence, one can say that commitment-based artifacts are reflections of one of the Scrum’s values. Commitments also increase “Focus,” another Scrum value.

I’ve mentioned the values here, because I believe they are very important, but you shouldn’t confuse values such as openness, courage, honesty, etc. with the value that you get while delivering an increment, although the latter is also important.

As the saying goes, “Culture eats strategy for breakfast.”

In my view, it’s actually the values and value-system which eat strategy for breakfast. Strategy execution is the downstream of culture. Culture is the downstream of human, team, or organizational values. And values are the downstream of the philosophy on which civilizations (or a team/organization) is based.

At times, values are thrown around like punchlines, brandished as political weapons, or misused for self-serving interests. It’s true adherence to values that really matters because without values, nothing really works. This is true for a person, team, organization, or even a civilization.

As we proceed through the other changes, I’ll continue to reflect on the Scrum values. 

Multiple Increments

Earlier it was mentioned that an Increment will happen at the end of Sprint. Now, within a Sprint, multiple Increments can happen.

An Increment happens when a backlogged item meets the DoD. Hence, an Increment can be created at any point of time during a Sprint. This is depicted in the below figure. 

As shown, at the end of the Sprint, we have Increments. Increments can also happen at any time during the Sprint. The new guide clearly informs that Sprint Reviews should not be considered “gates” for releasing value.

As there can be multiple Increments, the sum of all these Increments are presented to the (key) stakeholder at the Sprint Review. 

Introduction of Cadence

For the first time, we are introduced of a concept called “Cadence.”

This is an important introduction, which is missed by many Agile practitioners. Cadence is used in other Agile frameworks such as Kanban, and is basically a rhythm that gets developed as one continuously follows a set of events over a period of time.

In Scrum, the cadence is provided in the form of five events:

  • Sprint – the container event
  • Sprint Planning, Daily Scrum, Sprint Retrospective, and Sprint Review – the contained events within a Sprint

I’ll suggest that you read this change along with the previous change of “Multiple Increments.” As you go through these updates together, you can see two things emerge:

  • Development is happening in cadence, whereas,
  • An Increment can be there at any time during the Sprint.

You can say development (or build) of the product and incremental delivery have been decoupled. In fact, they can be thought to be of two streams as shown below.

As shown, the stream for cadence is decoupled from the stream for increment. The diamond shapes in the cadence stream denote the Sprint Reviews. While there is an increment at the end of the review, on-demand increments can happen at any time, as we see in the increment stream.

Cadence helps with inspection, which is one of the pillars of empiricism. This, in turn, drives another value of Scrum: “Openness.” 

Lean Thinking

Earlier the guide referred to empiricism. Lean thinking has appeared for the first time.

Empiricism is a practice which is based on knowledge coming from experience and what you know or have observed. The three pillars are: Transparency, Inspection, and Adaptation.

To include and encourage lean thinking, the wording in the guide has changed in quite a few places. For example, the guide notes: “Transparency enables inspection. Inspection without transparency is misleading and wasteful.” Again, remember that “Transparency” (or Openness) is one of the values in Scrum.

A key principle of lean thinking is to avoid “Muda,” a Japanese term meaning “waste.” When work is not done after being taken into a Sprint, the result is Muda. With DoD, Muda is avoided. Do remember DoD is the commitment for an increment. With DoD:

Introduction of “Why” in Sprint Planning

Other than “what” to do in the Sprint and “how” to do it, the “why” aspect has been introduced.

Earlier, before the start of Sprint Planning event, two questions were emphasized:

  • Topic – 1: What should be done in this Sprint?
  • Topic – 2: How do we do it within the Sprint?

In the new guide, emphasis has been given to Sprint Goal. Hence, we now have three aspects:

  • Topic – 1: Why is this Sprint valuable?
  • Topic – 2: What should be done in this Sprint?
  • Topic – 3: How do we do it within the Sprint?

This is shown in the below figure. 

Sprint Goal has to be collaboratively defined by the entire team. The introduction of Sprint Goal in the Sprint Planning event, reemphasizes a value of Scrum: “Focus.”

Single Scrum Team

Earlier, there was a Development Team within the Scrum Team. There is no ‘team within team’ now.

A Scrum Team is one, and it consists of the Product Owner, Scrum Master, and Developers. This is a step away from the “us-vs-them” mentality created with the term “Development Team” earlier. It also avoids a “throw-over-the-wall” mentality (i.e. my or my group’s work is done and now is the time to throw it over the wall, so that the other group takes care of it!)

Now, the team is considered to be a cohesive unit of people focused on the Product Goal. The PO, SM, and Developers are all intrinsic parts of the Scrum Team. The new version of the guide also notes that the team is the fundamental unit of Scrum.

The single Scrum Team concept enables two values of Scrum: “Respect” and “Openness.” With a single team concept, there is less likelihood of “us-vs-them” mentality.

Also, a single team concept with no hierarchies creates a culture where everyone knows that the team succeeds or fails together, hence candor goes-up. It’s likely to stop compartmentalization of members, prohibit group or community biases, reduce politics, and cripple finger-pointing, and eliminate blame-games and back-biting. If one team member is failing, it means the whole team is likely to fail with their ability to meet the goals of Sprints, the goal of the Product, or the honoring the DoD. The team moves towards, or strives to be, an indivisible whole.

Self-Managing Team

Instead of “Self-organizing,” the team is now “Self-managing.”

Agile teams are cross-functional meaning that they have all the needed skills to do the work and create value in each Sprint. Along with that, whereas the team was described to be self-organizing in the earlier edition, the terminology has now been changed to self-managing. There is a subtle difference between these two terms. Self-managed teams go one step ahead of self-organized teams.

A self-organizing team chooses who will work and how to do the work. A self-managing team, on the other hand, chooses who, how, and what to work upon. In my view, the team can consider the new aspect of “what,” because the PO is now explicitly part of the team.

It’s not that a team will be self-organizing from Day 1 or even within a few weeks of interactions. The team has to go through the stages of team formation, such as forming, storming, norming, and performing.

Also, with the introduction of “what,” the team decides which items are to be taken-up for the next Sprint. This, in turn, reflects another aspect of Lean Thinking: “Muri,” another Japanese term meaning “overburden.” As the team decides what items are to be taken-up, Muri is less likely to arise. When what items are determined at the beginning of the Sprint, it reflects another aspect of lean thinking: Just-in-time (JIT).

Not a Servant Leader, but a Leader who Serves

The Scrum Master being referred to as the Servant-Leader of the team has been removed.

The guide currently notes, “The Scrum Masters (SM) are true leaders who serve the Scrum Team and the larger organization.”

This enables the SM to play a larger role in the organization. The SM is not only now accountable for establishment of Scrum, the SM also leads, trains, and coaches the organization on Scrum adoption. He or she also advises the organization on Scrum implementation.

In my view, this is a positive change because I’ve noticed that the words, “Servant Leader,” have been weaponized by some teams. The SM is not a clerk or secretary to take notes during Sprint events and send meeting emails or reminders. The role of a SM is much bigger with a focus, not only on the team, but also playing a broader role in the organization. This larger aspect is emphasized by putting leadership first.

As you go through the new guide, you may also notice changes such as:

  • The three questions of Daily Scrum are no longer mentioned.
  • One process improvement item from Sprint Retrospective, which must be taken into the next Sprint’s backlog is no longer there.
  • The term “useable” has been used in place of the term “releasable,” among many others.

In this article, I’ve elaborated on some of the top changes. I hope you are not only aware of these, but understand the deeper, philosophical reasonings behind these changes in the Scrum framework.

--

This article was first published by MPUG.com on 29th December, 2020.  


References

[1] Online Course: PMI-ACP Live Lessons, Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] Book: I Want To Be An ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[3] The 2020 Scrum Guide, by Ken Schwaber and Jeff Sutherland