Sunday, November 27, 2022

Step-by-Step Guide: Install, Set-up and Run MS Project 2019/2021 with Agile Features (Online Desktop Client)

Summary: MS Project has full in-built Agile features available for the Online Desktop Client version. When customers purchase my courses of Mastering MS Project Agile and/or Certified Hybrid-Agile Master Professional (CHAMP) courses, the first question that comes up is: how to see these features in MS Project? 

In fact, many struggle to install and hence can't use the Agile and Hybrid-Agile features. In this post, you will learn how to install, set-up and run MS Project in a step-by-step manner.

Note: Though I've mentioned MS Project 2019/2021 software with Agile Features, it’ll work with the latest version of MS Project. I personally use the software. The software is released continuously and when you download, you will get the latest version. You have to just follow the below steps.

Frequently Asked Questions (FAQs)

First and foremost, I receive the below questions frequently from the customers, users and aspiring users who want to buy the courses. Hence, I’ll address them first.

Question – 1: I already have a licensed version of MS Project installed. It does NOT have Agile features. What should I do?

Answer – 1: Simply uninstall the existing software. Go ahead and install MS Project 2019 Online Desktop client. You can try for one month and more. 

If you want to revert back to your earlier version, then simply uninstall the current Online Desktop Client and install your earlier version. It’ll work as you have the licensed version.

Question – 2: I do NOT have any version of MS Project software installed. But I want to use the Agile features. What should I do?

Answer – 2: Follow the steps mentioned in this post. After the MS Project Online Desktop Client is installed, you can run and check the Agile features.

Question – 3: How do I know that the MS Project Online Desktop Client has installed properly with its Agile features?

Answer – 3: Follow the steps mentioned in this post. I’ve shown a clear demonstration on how to install, run and check the Agile features. In the final step, I've informed on the verification with respect to Online Desktop Client.

Question – 4: Will I get a PDF version for installation steps when I go for the courses of Mastering MS Project Agile and/or Certified Hybrid-Agile Master Professional (CHAMP)?

Answer – 4: Yes, absolutely. You will have detailed step-by-step instructions with complete explanation, when you subscribe to the either or both of the above courses. You will also have detailed video explanations on how to check the Scrum, Kanban, ScrumBan, Hybrid-Scrum, Hybrid-Kanban, Hybrid-ScrumBan with these courses. 


MS Project Agile/Hybrid-Agile Installation, Set-up and Run

MS Project Agile features for installed software in your computer is only available in the Online Desktop Client edition. It’s not available in any other version of the software. The MS Project for the Web, a new version of MS Project, is fully online or web-based. But it’s completely different. Hence, we will start with downloading the MS Project Online Desktop version and proceed with the below steps.

Step – 1: Know where the software is available

The software is available at the below link: 

As you can see there are three plans:

  • Project Plan 1:
    • Available for free one-month trial and then nominal payment.
    • This plan does NOT have Online Desktop Client.
  • Project Plan 3: [Use this plan]
    • Available for free one-month trial and then a bit more nominal payment
    • This version has an Online Desktop Client as shown in the column (check the next figure). 
  • Project Plan 5:
    • This plan also has an Online Desktop Client. 

You can learn more on these plans at the below link:

Specifically, in our case, we will take Project Plan 3. This has the least cost and maximum number of features available. Also, unlike Plan 5, for Plan 3 we don’t have to contact any partners.

As you can see the Desktop Client and its features can be used on upto 5 PCs.

Step – 2: Create an account at

The office portal the one where you have all the office related software available for download, such as MS Word, MS PowerPoint, MS Excel etc. If you don’t have an account here, you can create an account at

I assume you already have licensed version of the software available. That way, you can export easily to MS Excel or MS PowerPoint from MS Project software. Yes, MS Project software has a number of features, which you can work with or export to other office software.

After you have created an account at the Office Portal and logged-in, you will have following view. 

As shown, when you login:

  • On your left side, you will have the software available such as MS Word, MS Excel, among others.
  • On your right, you can install all the software as apps.

When you have a subscription for MS Project Plan 3 software, you can use the “Install apps” command on the right and install the MS Project software. This is another way to install the software.

Step – 3: Go to

As informed earlier, we are going to use Project Plan 3, which has the Online Desktop Client. Hence, in the link, we will use that plan.

The below view will be available for you.

In the above view, use the “Try free for one month” option (highlighted above). Later-on, you can pay to continue with the software. 

Step – 4: Provide the needed details to use Project Plan 3 

When you try free option in the previous step, it'll lead you to another page with the below view. 


There are a few steps involved such as providing your email id, verification and minimal business information. Once you are done you are subscribed to Project Plan 3!

Step – 5: Ensure to have the latest release at: 

It’s a good idea to have the latest release available for your software. The software gets updated frequently and with the latest release, you will have the latest features available. 

In the above link (, you will have the following view. 

In the above view, go to Settings > Org settings, which are highlighted. Here, we can have the latest software release setting.

In the Org Settings, select Release preferences under the Name column, as shown below. 

As you click on Release preferences, you will have the following view.


Ensure that the checkbox of "Targeted release for everyone" is selected. 

Now, you are fully ready to download the software and install.

Step – 6: Go to

As you click on the above link, we will find the following view. 

It’s possible that you may get the Download option instead of an Install option. In such a case, don't worry at all. It’s perfectly fine. Just download the software. Ensure that it’s compatible with your OS.

You can go for a 32-bit or 64-bit version of this software. 

Note: If you have purchased an office edition in 32-bit, then use the 32-bit version for Project Online Desktop client. 

Step – 7: Install the Project (Plan 3) software

Do remember that you are now effectively installing a subscription version of the software, with the Online Desktop Client feature as we have seen earlier.

In other words, you downloaded the client side of the software on your desktop via online. This will look exactly like Desktop editions with a slight twist, which we will see in the final step. 

As you install the software and continue, it’ll look as shown below, post installation. 

Step – 8: Check Agile (Scrum and Kanban) Functionality

Now that the software is installed on your desktop, you can run it. 

As shown, the software is now available on Windows Start command. It’s highlighted as Project. As you run the software, the following view comes-up. 

As shown, now you have, capability to run:

  • A Traditional Project,
  • A Sprints (Scrum) Project,
  • A Waterfall project, and also
  • A Kanban Project (it can used from the Waterfall project mode)
In-depth, hands-on videos are available on how to check on such projects with Mastering MS Project Agile and/or Certified Hybrid-Agile Master Professional (CHAMP) courses.

When you click on the Sprints Project command above, you will have the following view. 

Step – 9: Check the Account Information

Finally, you can check that the installed version is Microsoft Project Online Desktop Client.  

This can be seen by going to File > Account > and checking the Product Information as shown above. This is the twist I had mentioned in step - 7 earlier. If you want to have the latest updates, have it enabled to get the latest updates for this software.


[1] NEW Online Course: Mastering MS Project 2019 Agile (Scrum, Kanban and ScrumBan), by Satya Narayan Dash

[2] NEW Certification Course: Certified Hybrid-Agile Master Professional with MS Project, by Satya Narayan Dash

Wednesday, November 23, 2022

Unknowable-unknowns Vs. Unknown-unknowns in Risk Management with Emergent Risks and Novel Risks

As I frequently interact with project and risk management practitioners, the below two questions on unknowable-unknowns and unknown-unknowns come up. They are quite confusing for many. The existing literature doesn’t help as they are written with complicated language and/or complex explanations. The questions are:

  • What are the differences between Unknowable-unknowns and Unknown-unknowns? 
  • Where does emergent risk actually fit in (in the above context)?

To understand, let’s simplify. 

The Fundamentals

First, let’s understand, what is the difference between unknowable and unknown?

  • Unknown: You really don’t know. It’s definitive. 
  • Unknowable: You are not likely (or unlikely) to know. It’s probabilistic. 

When we say definitive, it’s certain that you don’t know. For example, it’s possible you don’t know some new technologies, design or frameworks.

When we say probabilistic, a chance factor comes in. There is a chance (usually high) that you don’t know. For example, when disruptive technologies start to pervade, you are unlikely to know the impact. 

Simply put:

  • When we say unknown, it means there is a lack of knowledge or untapped knowledge.
  • When we say unknowable, it means there is not only lack of knowledge, but also exploration is not probable. In this case, it’s untappable knowledge. 

Now, let’s see what are emergent risks and novel risks? 

Emergent Risks

As per PMI’s Standard for Risks in Portfolios, Programs and Projects, this is the definition of emergent risks:

“A risk that arises which could not have been identified earlier on.”

I agree with this definition, but not the subsequent explanation of PMI on emergent risks in the context of the unknowable, though I’ve adopted them in my books and courses. In this case, one can say these risks could not be identified because they were unknown at that time, but later on, the risks emerged.

When one says “emerge”, a pattern is forming, but not clear. It’ll emerge. 

Novel Risks

I provide this definition for novel risks:

“A risk that arises which was not probable (improbable) to be identified earlier on.”

Here you can say, these risks were improbable to be determined and later it came-up unexpectedly, hence the term “novel” or completely new – not emerging! 

When one says “novel”, there is no pattern formation at all. It is completely new. 

Also, did you notice the distinction in the definitions?

For an emergent risk, we could not have identified earlier, which can be due to many factors such as lack of knowledge, understanding or considering various scenarios. 

For a novel risk, we have a probability factor coming into play. It was improbable to be identified earlier because exploration of such a risk was improbable. 

Unknown-unknowns Vs. Unknowable-unknowns

Now, let’s see the difference between these two:

  • Unknown-unknowns: You don’t know that you don’t know. This is pure ignorance. Knowledge wise, it’s untapped knowledge. It’s part of the Complex domain.
  • Unknowable-unknowns: You are unlikely to know that you don’t know. This is not pure ignorance. Knowledge wise, it’s untappable knowledge. It’s part of the Chaos domain.

The emergent risks are actually unknown-unknown risks or simply unknown risks, whereas novel risks are actually unknowable-unknown risks or simply unknowable risks. Again, do note that my explanation differs from many, including PMI. The figurative representation is shown below.

I’d also strongly recommend that, you read the followings articles:

Cynefin Framework, Risks and Agile: Known-unknowns, Unknown-unknowns, and Unknowable-unknowns

Risk Classification: Known-knowns, Known-unknowns, Unknown-unknowns, and Unknown-unknowns


Combining all that I've explained:

  • Known-known is conscious knowledge or facts. You know that you know.
  • Known-unknown is conscious ignorance. You know that you don't know.
  • Unknown-unknown means unconscious ignorance. You don't know that you don't know.
  • Unknowable-unknown means unexplorable and unconscious ignorance. You are unlikely know that you don't know.

If you have understood so far in this article, then you have understood the difference between unknowable-unknowns, unknown-unknowns and the associated risks such as emergent risks and novel risks. 


[1] RMP Live Lessons - Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] RMP 30 Contact Hours, with Full Money Back Guarantee, by Satya Narayan Dash

[3] Book - I Want To Be A RMP: The Plain and Simple Way To Be A RMP, Second Edition, by Satya Narayan Dash 

[4] The Standard for Risk Management in Portfolios, Programs and Projects, by Project Management Institute

Monday, November 14, 2022

Risk Register and Risk Report: What Are The Differences?


Risk Register and Risk Report are two key artifacts in Risk Management. Risk Report has been introduced for the first time in the PMBOK Guide, 6th edition and continues to be there in the PMBOK Guide, 7th edition. Also, the Risk Register will be used in projectsprograms and portfolios as well as in Agile management.

In fact, in the latest PMBOK Guide, 7th edition, Risk Report is informed to be one of the commonly (and frequently, emphasis mine) used reports, if you are really doing risk management. The commonly used reports noted in the PMBOK 7th edition are:

  • Risk Report, 
  • Quality Report, and 
  • Status Report. 

Needless to say, reporting is an important aspect of management.

Also, if you are preparing for the Project Management Professional (PMP) exam or Risk Management Professional (RMP) exam, you have to clearly know the contents of both the register and report. Specifically for the RMP exam, from 2022, the PMBOK Guide 7th edition (and tacitly 6th edition) will be one of your reference sources

In this article, we will see the differences between these two key project and risk management artifacts in an exercise format. We will also see in which processes the content of these two project documents are populated. 

Content of this article have been taken from the following video courses, where in-depth explanation and guidance are available:

Now, let’s start with the differences between Risk Register and Risk Report. 

Differences (Exercise): Risk Register and Risk Report

As shown below, we have a table with Risk Register in the second column and Risk Report in the third column. Try to note down the differences between the Risk Register and Risk Report on your own first, before checking the answers. 

Were you able to find out at least five differences?

Scroll down to see the answers.

. . .

. . .

. . . 

In the below table, we have the differences noted.

Next, let’s try another exercise. 

Processes (Exercise): Risk Register and Risk Report

In this exercise, we have the Process Name(s) noted in the third column. You have to inform in which process (or processes), the content of the Risk Register and Risk Report are noted.

Following are the processes in Risk Management:

  • Plan Risk Management
  • Identify Risks
  • Perform Qualitative Risk Analysis (Perform QLRA)
  • Perform Quantitative Risk Analysis (Perform QTRA)
  • Plan Risk Responses
  • Implement Risk Responses
  • Monitor Risks

I believe you have tried it first on your own, before checking the answers.

Scroll down to see the answers.

. . .

. . .

. . . 

In the below table, we have the process names noted for the contents of the Risk Register and Risk Report.

A Sample Risk Register

Below is a sample of a real risk register.

As shown above, in the Risk Register, we have Risk ID, Risk SWOT value (threats or opportunities), Risk Title, Risk Pre-mitigation parameters such as probability, impact on schedule, cost, performance etc., and risk score.

A Sample Risk Report

Below is a sample of a real risk report.

As shown above, in the Risk Report, we have information about overall project risk, the project chances of success with respect to schedule and cost with probabilistic analysis, sensitivity analysis, summary information about individual project risks, risk audit information and a summary conclusion.

You can learn more on the 
flow of risk register and risk reports, and how they are populated as they pass through the risk management processes in the following article.

Fundamentals of Project Risk Management Framework


In my interactions, few managers, who understand the value of risk management, use Risk Register! On the other hand, Risk Report is almost unheard of, because organizations don’t take risks seriously. It creates problems later with many change requests (CRs) or issues overwhelming the projects, programs or portfolios. Do also note that issues are risks, which have already occurred. I’ve seen many such instances and projects running into real trouble. 

When you clearly know the content of these two project artifacts and know how they are prepared, it’ll help you immensely in not only managing the risks, but also scope management, schedule management and cost management aspects of a project. 

PMP Live Lessons and RMP Live Lessons:

PMP 35 Contact Hours and RMP 30 Contact Hours:

Saturday, November 05, 2022

Strategizing for Project Threats and Opportunities in Risk Management


Over a decade ago, I was put in charge of a group of projects. One of the projects had been running for almost a year, but had never seen a single live release to the customer! I realized there were too many unresolved risks, and asked the concerned project manager to put risk management, a new concept in the organization, as a top priority. Post identification and qualification of risks, any risk above the risk threshold value had to be brought down. If that was not done, I advised him no one should be allowed to work on the concerned project tasks.

This touched a raw-nerve.

One day a senior executive dropped by and asked about the guidance I had given to the project manager. In his mind, risk identification, qualification, and addition of reserves et al are sufficient, and I should not have stopped people from working on tasks.

My response was: “When you know a cyclone is going to hit in five days, do you wait to act on the fifth day or do you start immediately working to mitigate the expected impact?”

To elaborate a bit more, if a cyclone is about to hit, will risk identification help? Will risk qualification help? You know it won’t do much, though needed. How about quantification and adding reserves – say various cyclone shelters, food stock, etc. – will those help? Yes, but not fully. What is most needed in such a situation is risk mitigation. We can’t change the probability of the cyclone, but the first act of mitigation would be the evacuation of people. Risk mitigation is one risk response strategy.

In this article, I’d like to explore various such strategies.
At this stage, it’s important to note that risk response strategies are applicable in cases of both negative risks (threats) and positive risks (opportunities). You can learn more on individual project threats and opportunities here.

Risk Response Planning
The Project Management Body of Knowledge (PMBOK®) guide from the Project Management Institute (PMI®) has a specific process to develop various risk response strategies. It’s called Plan Risk Responses, and it’s defined as follows:

Plan Risk Responses is the process of developing options, selecting strategies, and agreeing on actions to address overall project risk exposure, as well as to treat individual project risks.

The goal here is to develop risk response options, strategies, and actions for both individual project risks and overall project risk. In other words, you are planning to minimize the threats (negative risks) and enhance opportunities (positive risks). With this process, the project manager allocates resources and inserts items and activities within the documents and the project management plan, in order to address said risks.

Obviously, both the Risk Register and Risk Reports are needed as inputs to address such risks (along with the Risk Management Plan). Remember, we are addressing both individual risks and overall project risk. See this depicted in the below flow diagram, with the highlighted process of Plan Risk Responses.

As shown, once you have the risk response strategies and associated actions, both the Risk Register and Risk Report have to be updated. You can learn more about the above flow diagram in this article on risk management framework.

Risk Response Strategies – What Happens?
In the Plan Risk Responses process, for the negative risks, we are trying to move the High Probability and High Impact risks to be of Low Probability and Low Impact, by taking response actions. The reverse is also true.

I’ve explained this in the below video [duration: 3m: 53s], the content of which has been taken from RMP Live Lessons, Guaranteed Pass. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.

Risk Response Strategies for Threats
Now, let’s look at various response strategies for individual negative risks or threats.

Escalate Response Strategy

The escalate response strategy is used when the project team or the project sponsor agrees that:
  • The threat is outside the scope of the project.
  • The project manager does not have the authority for the proposed response.
At this point, the risk is escalated to a program or portfolio or other suitable level. The project manager determines who should be notified. The escalated entity should be notified and the entity should also accept it. After escalation, the risk is not monitored by the team, but may be recorded in the Risk Register.

Example: A risk occurring in another project is impacting your project, so you escalate it to the level of a program or a portfolio.

Avoid Response Strategy
This response strategy is usually used for high priority risks, i.e., risks with high probability and a big negative impact. We can do two things here, either:
  • Eliminate the risk completely, or,
  • Protect the project from its impact.

Most of the time, the first (avoidance or elimination) is taken by changing the project management plan.

Example: You use a reliable technology platform for your project, instead of an unreliable, but cutting edge one.

Transfer Response Strategy *** UPDATED ***
Transfer of a risk is done by shifting the impact to a 3rd party, who will own the response. This method is usually best used for low impact risks. A risk premium has to be paid to the 3rd party.

Example: You go for an incentivized contract, such as Cost Plus Incentive Fee (CPIF), to transfer the risks to the buyer.

For more information about incentivized contracts, go to these articles of point of total assumption and range of incentive effectiveness. While the former is for Fixed Price Incentive Fee (FPIF) contract, the latter is for CPIF contracts. Do note that by transferring the risks, they are not gone! Rather, they will be addressed by the entity to which risks have been transferred.

Mitigate Response Strategy *** UPDATED ***
With a mitigate response strategy, you try to reduce the probability and/or impact of the risk. This is used for high priority risks (with high P and high I values). After reduction, the risk score should be within an acceptable threshold limit. You can learn more about the usage of risk threshold in this article on end-to-end risk management.

Example: You first build a prototype for a highly scalable product before going for full-fledged development.

Where mitigation is not possible due to probability, it’s best to look for mitigation responses which pull down the impact.

Accept Response Strategy *** UPDATED ***
In risk acceptance, no action is taken unless the risk occurs. Like transfer strategy, it’s used for low priority threats or used when it’s not possible to have a cost-effective solution which addresses the threat. The Project Management Plan is usually not changed in this case. A common risk acceptance strategy is to use contingency reserve.

Example: If there are frequent climate changes, you may accept such as a risk for your project.

Risk Response Strategies for Opportunities
Like threats, there also can be a number of risk response strategies for individual positive risks or opportunities.

Escalate Response Strategy
It’s very similar to the one we have seen earlier for negative risks, except that in this case it is for positive risks or opportunities. It’s used when the project team or the project sponsor agrees that the threat is outside the scope of the project and the project manager does not have the authority for proposed response.

Again, after escalation, the risk is not monitored by the team, but may be recorded in the Risk Register. This is another key distinction for this strategy compared to other strategies.

Example: A benefit occurring in another project has implications for your project and you escalate such to the level of a program.

Exploit Response Strategy
With this risk response strategy, you seek to eliminate uncertainty by ensuring that the opportunity is realized or that it definitely happens. It’s used for high priority opportunities.  A payment of a risk premium can be involved for the party taking on the opportunity.

Example: Using talented resources to complete work early with less cost.

Share Response Strategy
In this case, you allocate some or all of ownership of the opportunity to a third party. Because it’s a share response strategy, both sides benefit – the first owner and also the sharing owner. It can be considered the “mirror” part of transfer response strategy, which we have seen earlier for individual negative risks.

Unlike transfer, it is not completely handed over to another party. It is shared; however, risk sharing, like transfer response strategy, often involves premium payment.

Example: Your organization forms a joint venture or partnership with another organization to execute the project considering the benefits involved for both.

Enhance Response Strategy
With this response strategy, you increase the probability and/or the impact of an opportunity. Early enhancement is considered more effective. If you cannot increase the probability, try to increase the impact.

Example: You add more features to a product to sell more products.

Accept Response Strategy *** UPDATED ***
In this case, if the opportunity arises, it will be taken advantage of, but not actively pursued. It’s usually considered for low priority opportunities or if no cost-effective solution is available.

Example: A new project will takes advantage of a tax break, if an expected legislation is passed.

A Real-World Example and Exercise
Now that we have reviewed various risk response strategies, let’s do an exercise.

Scenario: You are driving to reach your office and become aware of possible heavy traffic on your traveling route through a radio warning or via global positioning system (GPS). Regardless, you have to reach your destination to attend an important meeting. You have the following options available, outlined in the below table.


Can you tell, based on the situation presented, which risk response strategy will best fit? Do note that the scenarios presented are for negative risks, and your response should be one of the strategies for each question.
I would suggest that you try this exercise on your own first before checking the solution, but I’ve explained in the below video [duration: 7m: 20s], taken from my RMP Live Lessons course what I advise. This clip also addresses an additional question related to contingency reserve and how it’s used in our scenario.

As we reach the end of this article, I’d like to draw a comparison between the risk response strategies for threats vs. opportunities in the below table:

Finally, it’s not that an individual threat will have a single response strategy. If a threat can’t be avoided, then a project manager can mitigate to a level where it becomes viable to accept or transfer it. Similarly, if an opportunity can’t be fully exploited, it can be enhanced to a level where it can be viable to accept or share it.


This article was first published by on 3rd May, 2022. This is an updated and refined version.

[1] Course: RMP Live Lessons, Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] Course: RMP 30 Contact Hours with Money Back Guarantee, by Satya Narayan Dash

[3] Book: I Want To Be A RMP, The Plain and Simple Way, Second Edition, by Satya Narayan Dash

Wednesday, October 26, 2022

Agile Asanas: Closing A Project Vs. Closing A Sprint


Any genuine management practitioner will tell you that a project has to be closed, irrespective the methodology or framework being used. If it’s a traditional project and/or a project having multiple phases, then not only the project has to be closed, but each project phase has also to be closed. 

[ This post is part of the Agile Asanas series. 

To read all posts in Agile Asanas series, use this link. ]

Closing a project entails a number of activities and it’s advantageous for the project manager to do so. 

Now, because a Sprint is considered to be a mini-project, it also has to be closed, irrespective of the decomposition patten being followed such as:

  • Project, Release, Feature, Sprint, Use Story
  • Project, Feature, Release, Sprint, Use Story
  • Project, Epics, Feature, Sprint, Use Story
  • Project, Sprint, User Story

Going forward, I’ll be using the decomposition pattern of Project > Release > Sprint > User Story. 

Recently, I wrote a couple of articles regarding project closure and Sprint closure. I’d strongly recommend that you read both of them along with this piece. 

In this article, we are going to explore the differences between project and Sprint closures. For management practitioners, who want to be proficient across the spectrum of project life cycles and development approaches, it’s important that you know the differences.


First the definitions. 

A project is defined by the Project Management Institute (PMI) as follows:

A project is a temporary endeavor to create a unique product, service or result.

Do note that the definition says that a project creates something unique. It can be a product, service result. This definition is not about a deliverable or increment at the end of the project – rather, it’s a finish product. 

I define Sprint as follows:

A Sprint is a time-boxed iteration event within the Scrum framework.

The Sprint event contains four other events: Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Each Sprint can be considered to be a short project as noted in the latest Scrum Guide, 2020.

An increment of value is delivered at the end of the Sprint or prior to the Sprint. An increment is a step towards the Product Goal. You can learn more on increments and Product Goal in the below article:

Top Changes to Know for Scrum Guide 2020

With these foundational understanding, let’s see the differences one by one. 

Difference – 1: You close a Project once, but close Sprints many times.

A project is closed only once. If a project has multiple phases, then each phase is closed separately and these steps can happen multiple times. However, the project closure is the final one and happens once.

On the other hand, the Sprints are closed multiple times. After all, a project can have many releases, which in turn will have many Sprints. 

All these Sprints can be closed within the life cycle of a project. 

Difference – 2: Final increment is at the end of the Project, intermediate and/or multiple increments can happen anytime within a Sprint.

As we saw earlier, a project creates/builds a product (or service or result). Basically, it’s a deliverable or collection of deliverables. A deliverable is a uniquely verifiable product (or service or result) that is produced to close a project or phase. 

On the other hand, an increment (similar to deliverable) is produced at the end of the Sprint or prior, but within a Sprint. The increment given at the end of the Sprint is a sum of previous increments. An increment is not a finished product. 

Difference – 3: Resources are released when a project is closed. Resources are likely to remain when a Sprint is closed.

When a project is closed, all the resources are released. You, as a Project Manager, has to do it because you are accountable for the time spent and cost involved for the resources.

But when you close a Sprint as a Scrum Master, you don’t release the resources. Because those will be needed in the upcoming Sprints. 

Do note that in Agile, the team is cross-functional, self-organizing and self-managing, but procurement, hiring and release of resources (both human and non-human) are facilitated by the Product Owner and/or the Scrum Master. 

You can learn more roles being played in Agile and Traditional environment in the below article:

Agile Asanas: Mapping Traditional Project Roles to Agile Frameworks

Difference – 4: Final Report is given at the end of the Project, whereas usually Burndown Chart is enough for a Sprint end.

The final report given at the end of the project is quite exhaustive. This is the summary of project performance. It informs if the scope, schedule, cost and quality objectives are met, the achievement of business needs/objectives of the project, among others.

But, when a Sprint is closed, there is no such exhaustive reporting or documentation. Usually, Burndown Chart is enough to inform on the work completed. 

If you want, you can show certain additional information in your Sprint Report such as features completed vs features planned, velocity (story completed vs planned), issues faced, risks register and addressed. But remember, in Agile, one the values is this:

Working software/product over comprehensive documentation.

Difference – 5: Usually Projects will have Lessons Learned Meetings, whereas Sprints will have Retrospectives!

You may have noticed that Lessons Learned Meeting and Retrospectives are used interchangeably. But there are subtle and important differences. 

Lessons Learned Meeting is a periodic meeting, where the team meet to determine what they could do better in the future with a focus on improving team performance. Lessons learning happen throughout the life cycle of the project. However, the final Lessons Learning Meeting happens at the of the project. The ‘lessons learned’ is then archived into the organizational repository. 

Retrospectives, on the other hand, happen for the iterations or Sprints in our case. It has a recurring pattern and specificity. Here, the team meets how they can improve the process and product in the upcoming Sprints. 

Retrospective is a form of lessons learned meeting, but they are not the same.

Difference – 6: Project documents are closed and archived. A Product Backlog is not closed or archived. 

Project documents such as Requirements Documentation, Scope Statement (part of the Project Management Plan) are closed/completed/reviewed and archived at the end of a Project.

A Product Backlog used in a Scrum Project is not closed and archived when a Sprint gets closed. It’s a live document and continuously gets updated. 

In fact, at the end of the Sprint, the backlog is likely to get updated with the improvement items coming from the Sprint Retrospective event. Again, notice that it’s Sprint Retrospective, not Sprint Lessons Learned Meeting! I’ve already differentiated the two in the earlier point. 

Difference – 7: A project is a temporary endeavor with a longer time-span, whereas Sprint is a short time-boxed event.

This comes from the definition itself, which we saw earlier. A project is not timeboxed, i.e., when the time is over the project is over! The time-span of a project can be elongated or shortened. 

On the other hand, a Sprint is always a timeboxed event. If the Sprint duration/length is of two weeks, then the Sprint has to be closed at the end of two weeks. 

It doesn’t matter if the work taken to be completed within the Sprint is complete or not. It has to be closed! 

Difference – 8: Formal activities for contract closure happens at the end of the project, whereas contracts can be closed within a Sprint.

This difference is slightly tricky. 

At the end of the project, one considers both contract closure (all final payments made, no outstanding claims etc.) and administrative closure of the contract (confirming formal acceptance of deliverables, finalizing open claims etc.)

A contract can be closed during a Sprint when the deliverables have been given by the contractor and accepted. However, the administrative closure of the contracts can be time consuming and a Sprint is timeboxed. Hence, it’s not preferably done in a normal Sprint.

Difference – 9: Project Audits happen at the end of a project, but doesn’t usually happen within a Sprint.

The project audit is mainly to check the project success or failure. The success criteria are documented in the Project Charter document.

However, an audit usually doesn’t happen at the end of a Sprint. Audit is time consuming on its own and hence, a short time-boxed duration of Sprint can’t really accommodate the need.  

Also, as the customer (or proxy of the customer, which is the PO) is directly involved daily in Sprint, one need not go for an audit to check the success and failure for a project. 



There are also similarities between the closure of a project and a Sprint. Below, I've noted some examples:

  • Acceptance of deliverables/increments happens at the end. 
    For a Sprint, the acceptance (or rejection) happens in the Sprint Review event.
  • The increment is handed over to the operations (in Project).
  • In Agile, the increment is directly deployable and hence, usable or can be with the ops team (DevOps).
  • Both Project and Sprint closures focus on value delivery.
    Increment must be of value to the end customer/user when delivered, so also a Project’s deliverables.
  • A project can be prematurely closed, so also a Sprint.
  • A project can be abnormally terminated, so also a Sprint. 

I believe with this you now have a fair understanding of the various differences between project and Sprint closures. If you have more things to add or have other comments and suggestions, do leave them in the comments section below.


[1] ACP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] PMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash