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.
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
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 meets to determine what they could do better in the future with a focus on improving team performance. Lessons learning happens 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.
--
Similarities
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.
References:
[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
