Showing posts with label Agile Project Management. Show all posts
Showing posts with label Agile Project Management. Show all posts

Tuesday, March 12, 2024

Sprints at Scale: Working with 10, 100, 1000, or More Sprints in A Scrum Project


A Sprint is a mini-project and usually has a length of 2 weeks, though it can vary from 1 to 4 weeks. While running Sprints for a big project using Scrum framework, one can run 10, 100, 1000, or more Sprints. The number of Sprints goes-up when the Sprint length is shorter – say 1 week. This scenario highly possible.

Do not confuse Sprints at Scale with Agile at Scale, where multiple teams can work on multiple Sprints.

Now, questions can be:

  • How do you manage so many Sprints?
  • If you are using a software tool, how do you manage them?
  • Is it possible to have the current Sprint being shown first in the tool?
    (with all other Sprints)
  • Is it possible to show the work items for the current Sprint first?
    (a view showing all the Sprints)

These questions are very pertinent for any Scrum Master, Product Owner or an Agile Project Manager. In fact, recently I received such questions from Agile practitioners, who have been using my courses.

Let’s see how to manage a large number of Sprints and the answers to the above questions. 

Our Plan with Epics and Features

Our current plan is shown below and at a high-level:

  • There are 5 epics, from Epic 1 to Epic 5.
  • Each epic is broken into 10 features. In total, there are 50 features.
  • These features will be associated with the respective Sprints. 
  • One feature will be completed in one Sprint. For example, feature 50 will be done in Sprint 50. 

This is shown below in the Gantt Chart view of MS Project. 

These you can add in the Gantt Chart view or you can use the Sprint Planning Board or Sprint Planning Sheet views. 

As shown, we have features numbering up-to Feature 50. When you switch to the Sprint Planning Sheet, you will get the following view. 


Plan for the Sprints

To associate with Sprints, we need to create the Sprints first. These can be done using Project tab > Properties group > Manage Sprints command. 

As you can see, we have 50 Sprints planned now. 

Associate with the Sprints

One can use various possible views to associate the feature items with Sprint, but the most used ones (and recommended by my courses) are the Sprint Planning Board and Sprint Planning Sheet views of MS Project Agile software tool.

Using the Sprint Planning Board, for example, I’ve associated a number of features items as shown.

You have to simply drag and drop the items from the No Sprint column to the respective Sprint column. But then we have some constraints here!

  • When it reaches Sprint 5, then the board view on the left does not show the feature items. If you have to associate with Sprint 50, then you have to drag it all the way up-to Sprint 50, which is on the extreme right.
  • If you want to see only the last 3 Sprint items, i.e., Sprint 48, Sprint 49 and Sprint 50, then we also have to use the horizontal scrollbar to the end.

Hence, the better view to use in this case of having a large number of Sprints will be the Sprint Planning Sheet view. This is shown below. 

As shown, you have to just scroll down and associate the Sprint in the popped-up, drop-down or show-up list. Isn’t is very easy this way?

Show the Latest 3 Sprint Items first

Another issue is to show the last 3 Sprint items first. This cannot be done using the Sprint Planning Board view as the filters, groups are disabled in this view.

But you can circumvent it using the Sprint Planning Sheet view and applying the built-in Sprint group.  

Do note the change in order from from Ascending to Descending. That way, the latter Sprints will be shown on top. 

Sprint Grouped View

As you apply the above modified Sprint group, you will have the latter Sprints and the associate work items shown on top. The initial Sprints such as Sprint 1, Sprint 3 or Sprint 5, will be shown towards the bottom.  

Another Way to Show

Some of you may not want to apply to the Sprint group, but just want to see the latter Sprint items on top for quick usage. In that case, you have to change the sorting and sort it by Sprint ID as shown below. 

The Sort command dialog box can be seen by going to View tab > Data group > Sort > Sort By... command. 

Do note the change the order of sorting to Descending. That way, the latter Sprints and associated work items will come on top. 

When you apply this sorting, the Sprint Planning Sheet will come as shown below. 

As shown:

  • The work items for Sprint 50, Sprint 49 and Sprint 48 are shown on top.
  • The work items for Sprint 1, Sprint 2 etc. are towards the bottom.
In this case, we didn't apply any group, but just sorted items with Sprint ID field.

References

[1] Video Course: Mastering MS Project Agile, by Satya Narayan Dash 

[2] Certification Course: Certified Hybrid-Agile Master Professional (CHAMP), by Satya Narayan Dash 



Friday, March 17, 2023

A Masterclass in Leadership: Leadership, Leadership Levels, Leadership Styles and Qualities for Project Managers


We need a leader. Courageous, self-sacrificing people, setting examples for all of us. Everybody loves a leader, people line up for ’em, cheer for ’em, scream their names, and years later tell how they stood in the rain for hours just to get a glimpse of the one who told them to hold on a second longer.

– From the movie, Spiderman 2


The above, slightly paraphrased quote comes from the Spiderman 2 character, Aunt May, an old, frail-looking, but very warm, kind, and gutsy woman. She taught the young, down, and dejected Peter (Spiderman) the basics of leadership. One important part in the quote is courage.

Consider a big-budget movie being produced with hundreds of staff working on it. There are multiple managers also putting forth their best efforts, but many think the movie will not succeed in the market.

A leader is one who stands in front of everyone and calls out, “Wrong movie!” It takes courage to say that. Imagine the opposition and backlash. Some managers may negate it, or even scoff at it and indicate they are making progress. But what is the meaning of “progress” if you are building the wrong product?!

Leaders will have a vision and long-term goals, with which they are able to foresee how things will play out. Managers execute that vision. Leaders don’t always know the terrain, hence they navigate with something like a compass. Managers have to know the terrain, and hence, need to use maps. Leaders constantly monitor the environment and change directions. They are change agents. Managers use roadmaps and follow directions. They are change adaptors.

So, there’s a difference between managers and leaders?

I see it this way. Every leader has management capabilities. But every manager doesn’t have leadership capability. A truly good manager is also a very good leader. Management is about meeting objectives, whereas leadership is about purpose, passion, and enabling people to be successful.

With this background in mind, let’s turn to project management and start with the definition of a project manager (PM). In this article, I’d like to explore how leadership can transform management roles.


Project Manager as the Leader

I define a project manager as follows:
A project manager is an individual on the project formally assigned to lead the project team in order to meet the project objectives.

The Project Management Institute (PMI) in its definition also emphasizes leadership aspects, and I quote: The project manager is the person assigned by the performing organization to lead the project team that is responsible for achieving the project objectives.

Did you notice the underlined emphasis? It’s not about managing the project team, but about leading the team.

We can see that the leadership aspect is very important. I define leadership for project managers as follows:

Leadership is the capability to influence people through inspiration toward the desired outcomes of the project.

Why is this needed? Projects are unique endeavors and unlike operations, where roles and responsibilities are often established. Because of this unique, cross-functional, and sometimes even cross-organizational nature, projects demand a unique need: effective leadership.

This article focuses on PMs, but the content can very well be applied to a variety of management roles and spheres of life. In fact, many executives show a complete lack of leadership, though they may be very efficient managers.

Notice the term “efficient” being used for managers. Leadership is not about efficiency, but about effectiveness. Management is about hands (efficiency), whereas leadership is about heart (effectiveness). To understand this aspect more, let’s see the differences between management and leadership.

 

Leadership Vs. Management *** UPDATED ***
As we have seen, the project manager is the leader of the team. This is irrespective of the organizational structure. However, leadership and management are not the same.

Management involves directing the team to move from one point to another with a known set of expected behaviors. Leadership is not about directing, but about guidance with discussion and dialogue (not debate) from one state to another.


The comparison table below notes a few more differences between management and leadership.


Now, you may be wondering how one can have such diverse thinking and such a leadership mindset at the same time? The key is finding a balance based on the situation and the context.

Authority Vs. Leadership *** UPDATED ***
In many cultures, leadership directly equals authority. Command and control is the only way to get things done.

Putting that into an organizational perspective, line or functional managers mostly follow one leadership style: command and control (autocratic), because they control salaries and raises.

However, as a project manager, most of the time, you won’t have this form of formal or positional power with its uses and/or parenthetical abuses. The best thing to do in such a case is to recognize that leadership is not authority.

Authority is given to a person by formal means, document, or title, but the following is also true:

  • Authority may not motivate. If that were the case, every country would produce a hundred Olympic gold medalists. Does that happen?
  • Authority doesn’t mean expertise. A person with high expertise, knowledge, and skills is, in fact, more followed than one with authority.
  • Authority doesn’t mean respect. Intrinsic respect from one’s heart is different from enforced respect.
  • Authority doesn’t imply trust. People may comply with authority, but don’t always commit to it.

So, what should one do? I’ll outline two things I have learned:

  • Recognize that the best form of power is not formal. It is expert power, relational power, and persuasive power, among others. Such is exercised mostly through inspiration, because your actions - not words - inspire others to dream, act, and be more.
  • Understand that leadership styles can vary. It’s best to apply leadership styles based on context and situation. We will review several leadership styles in a moment.


Leadership Growth Levels
*** UPDATED ***
The growth levels of leadership are depicted in the below figure. This is based on my research, experience, and over a decade of interactions with thousands of managers. You may be seeing it for the first time. It is taken from my new course: A Masterclass in Leadership.


The lower levels of leadership are Positional (Level-1/L1) and Relational (L2). At L3, Inspiration, you have started to truly move up. When you deliver results (L4), you are established as a leader. The higher levels of leadership are Mission (Purpose), and Passion. The highest level is Culmination (L7), which very few reach.

Siddhārtha Gautama, known worldwide as the Buddha, the self-awakened and enlightened one, was one such leader in spiritual dimension. The teachings of leaders at the highest-level echoes in eternity.

Such a leader doesn’t want to be photographed everywhere, but people want to be photographed with the leader. The leader doesn’t put his picture everywhere, but people carry his picture and frame it inside their homes. The leader doesn’t pay the media to promote him or her 24*7 as we see today, but people come voluntarily to listen as they can smell: a real change is in the air.

I’d also like to say the best leaders are finally invisible. This type of leader is not seen but felt because he has enabled other leaders!

Leadership Styles
Various leadership styles are noted and described in the below table:


So, which leadership style is the best?

My answer to that is: not one in particular, as leadership style depends on a variety of factors. Sometimes, you may have to combine multiple leadership styles.

A Leadership Style Exercise
Let’s do an exercise to understand leadership styles better. In the below table, we have a number of situations. Think about which leadership style fits the particular situation.
 
The answers are explained in the below video [Duration: 04m:52s], which I’ve prepared in support of this article. The content of it is taken from my leadership course. Additional explanations and new leadership styles are also provided. For a better audio-visual experience, you may want to go full HD and plug-in your earphones.



Conclusion *** UPDATED ***

Before I sign off, I want to mention some frequent questions that come up regarding leadership.

Why does leadership fail?

One key reason is that leaders don’t follow their own preaching! The leader must role model the behavior he or she is expecting from others. It’s the ‘setting examples for all’ part in the opening quote.

How does one become a leader?

Also from Aunt May:

“I believe there’s a hero (leader) in all of us, that keeps us honest, gives us strength, makes us noble, and finally allows us to die with pride. Even though sometimes we have to be steady and give up the thing we want the most.”

An oft-ignored leadership quality is sacrifice. As a leader, you have to sacrifice a lot. You have to give a lot without expecting anything in return. Managers don’t sacrifice, but for a leader it’s a must.

Many don’t understand the importance of sacrifice. This is important because to get you must give first. It’s paradoxical, but true. But how many of the currently “supposed leaders” do that? You know the answer! You see, true leadership is exceptionally hard.

A teary-eyed, but more determined, an emotionally choked, but raring to go Peter gets Aunt May’s message and understands one painful aspect of leadership – making a lot of sacrifices, but still being hated. He also understands there are many who also love him. And he gives it another try the very next day. 

As Aunt May rightly tells, the hero is inside you. A leader is also inside you. Search for that leader, and when you discover it, nurture and expand it with the levels and styles we have reviewed. The path may be long and arduous. Sometimes you might stumble or even fall. But, if you are true to your heart, you are unlikely to be disappointed with the result.

I wish you all the very best in your journey and welcome your thoughts and comments. 

--

This article was first published by MPUG.com on 13th September, 2022. This is an updated version.



References
[1] NEW Course: A Masterclass in Leadership, by Satya Narayan Dash

[2] A Guide to the Project Management Body of Knowledge, by Project Management Institute


Saturday, December 24, 2022

What’s New: Management Yogi's Certified Hybrid-Agile Master Professional (CHAMP)



I’m pleased to announce a complete update for the below unique, hands-on, practical oriented, comprehensive course:

CERTIFIED HYBRID-AGILE MASTER PROFESIONAL (CHAMP) 

This course was available to Hybrid-Agile practitioners by the end of last year, 2021. Since then, it has been used by many professionals around the world. It’s a complete video course on Hybrid-Agile Management with both theory and practical, covering Hybrid-Scrum, Hybrid-Kanban and Hybrid-ScrumBan

This is the only such course in the world with a very strong emphasis on hands-on, practical applicability and in-depth learning. Literally, there is no such certification in the world. You can make your search!

You can refer to the earlier post on this course in the below link:
https://www.managementyogi.com/2021/11/certified-hybrid-agile-master-with-ms-project-online-course.html

The updates have happened after months of preparation, inputs from users/learners of this course. A number of inputs have been taken from real-world Hybrid-Agile practitioners. Also, over the course of last year (2021) and this year (2022), I've published a number of articles which generated a number of questions and feedback. Hence, this update. 

For existing customers of this course all the below updates will be FREE of cost.

What’s New in the Course – CHAMP Certification?

Below are the top highlights for the updates to this certification course. 

1. The Course and Certification has been RENAMED.

Earlier the course was called “Certified Hybrid-Agile Master”. It has been renamed as “Certified Hybrid-Agile Master Professional” or simply CHAMP certification. It sounds better and post certification you can put it in your signature. 

Note: There is no extra certification cost. It's part of the course package.

2. TWO NEW Full-length Question and Answer sets.

This certification course now comes with two full length question sets. In earlier edition, the question sets were not available. The question sets will have 50 questions each with detailed answers. This will help you master the concepts of Hybrid-Agile management. 

3. A NEW Step-by-Step Guide for MS Project Agile installation.

MS Project Agile installation (MS Project Online Desktop Client) is a must to pursue this course. However, as seen in the last one year, quite a few struggle with the installation of the software. Hence, a step-by-step guide has been made available for all course subscribers. 

The step-by-step guide will be downloadable for you. 

You can learn the primary steps to install MS Project Online Desktop Client in this post. Detailed documentation for download will be available for course subsribers.

4. A NUMBER of NEW practice questions for every lesson.

In the earlier version of the course, no practice questions were available. Based on inputs from course subscribers, a number of practice questions have been added for every lesson.

You have to complete the videos, do the exercises and immediately attempt the practice questions. You will also have detailed answers available. This will help you master the concepts and prepare for the CHAMP certification exam. 

5. A number of NEW Agile Tips and Tricks.

The course now comes not only with tips and tricks for MS Project, but also tips and tricks with MS Project Agile with emphasis on Hybrid-Scrum, Hybrid-Kanban and Hybrid-Scrumban management. Together now you have 140 tips and tricks. All of these will be downloadable

Combining the tips given throughout the discussion of this course and new tips provided, you will have 100s of them. 

6. NEW Notes for Theory part of CHAMP course.

A number of learners (customers) of this course wanted to have theory notes of this course. It is not available for the theoretical aspect of Hybrid-Agile management. The practical aspects are demonstrated with videos. 

The theory notes will be downloadable for you.

7. Complete CHANGE for existing questions. 

The questions are now mostly situational. The question also has a mixture of theory (20%) and practical (80%). With this, you will have a better understanding of real-world Hybrid-Agile management.

Do note that you have to take the Certification Exam, which is part of the course package. These questions are also now completely changed.

8. UPDATED Videos in the CHAMP certification.

Few videos are updated with more detailed explanations. The course has been informed to be very exhaustive by Hybrid-Agile practitioners. These additions will add more depth to the course.

9. UPDATED Course Index File.

As the course has seen a number of changes, the index file has also been changed. It’s available towards the end of this post with the latest changes and updates.

Top Features: Certified Hybrid-Agile Master with MS Project

  1. Total Video Duration: 14+ hours [updated]
  2. Number of Videos: 138 [updated]
  3. Number of Lessons: 10 (+2) [1 new]
  4. Two full-length Q&A Sets: Each set 50 Q&As [newly added
  5. Total Number of questions, including lesson-end: 150 (approx.) [newly added]
  6. Total Exercises (Practical): 100+ [downloadable]
  7. End-course exam and credential as a Certified Hybrid-Agile Master Professional (or CHAMP)
  8. 140 of tips and tricks on MS Project and MS Project Agile [new, downloadable]
  9. Step-by-Step installation guide for MS Project [new, downloadable]
  10. In depth understanding of Hybrid Scrum, Hybrid Kanban, and Hybrid ScrumBan.
  11. Ability to apply the concepts with the Hands-On tool of MS Project Agile.
  12. Generate various reports such as Burndown/Burnup Chart, CFDs, Hybrid Sprint Reports, Histograms and Pie Charts, Earned Value reports, among many others.
  13. A large number of exercise and solutions files (over 100), which you can download, use and practice.
  14. A large number of tips and tricks points to know throughout the course.

The details on it this course, with information on additional features, are available also available at:

https://www.managementyogi.com/p/certified-hybrid-agile-master.html


What is the Certification Offered by CHAMP Course?

This course comes with an end-exam with a set of questions, which covers both theory and practical of Hybrid-Agile Management. 

The exam has 50 questions to be taken in 60 minutes (1 hour). To clear the exam, you need at least a 70% score. 

With completion of the course and clearing of the end course exam, you will receive the unique credential: Certified Hybrid-Agile Master Professional or CHAMP.

What is Full Money Back Guarantee for CHAMP Certification?

The premise is simple.

Go through the complete course for 15 days. 100% video content of this course will be available to you. If you don’t like the course, I’ll refund your full money. 

Note: You can also evaluate the videos before paying any money. Twenty (20) videos will be available for your evaluation, even before your purchase.

Applicability and Validity: CHAMP Certification

  • Theory Used: Hybrid-Agile Management combining Waterfall, Scrum and Kanban
  • Software Used: MS Project 2019 Online Desktop Client 
  • Theory Pre-requisite: Project Management, Scrum and Kanban Frameworks
  • Software Pre-requisite: MS Project 2021/2019/2016/2013 and MS Project 2021/2019/2016 Agile
  • Course Duration: 3 or 6 months from the date of purchase
  • Price: $95 USD / Rs 7,599 (for 3 months)
              $159 USD / Rs 12,719 (for 6 months)
  • Payment – paypal.me/managementyogi
    (Login, Send your payment to paypal account of ndsatya@gmail.com, Enter the amount; Invoice will be generated after payment)
    OR, you can pay via Bank Transfer or Payment. For this, please send a mail to managementyogi@gmail.com to get account the details.
  • Available since: November, 2021 (Updated December, 2022)
  • Primary Format: Video 
  • Course Extension: As per your need
    (Price calculation will pro-rata)
  • Status: Available
    (accessible via laptop/desktop)

Updated Course Index: CHAMP Certification

The complete course breakdown for the CHAMP certification course is shown below, with the new and updated ones highlighted in green. It details the hours of learning, number of videos and practice questions, full-length question sets along with various hands-on exercise details. You can scroll to see the full content.



Conclusion

With this certification course, you will have mastery over Hybrid-Agile Management. This uniquely credential of CHAMP also establishes you as a solid professional in Hybrid-Agile management space.


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

Conclusion

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:

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 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

 


Wednesday, September 14, 2022

Building and Analyzing Kanban Cumulative Flow Diagrams with MS Project Agile


Like Sprint or Release Burndown charts in Scrum, cumulative flow diagrams (CFDs) are frequently used in projects using a Kanban framework. This is because one of the fundamental aspects of Kanban is this: Manage the flow. With a cumulative flow diagram, we can manage the flow of work.

Imagine an Agile development team is delivering a number of features on-demand. The team is following a Kanban mode with Testing being a workflow state. If the team has many features developed, but is waiting to test, then the development band/state in the Kanban board will be narrow, and the testing band will be wide. A cumulative flow diagram assists.

The content of this article has been taken from these new courses:


The Cumulative Flow Diagram Basics *** UPDATED ***

A Kanban cumulative flow diagram shows work in progress in the Kanban board. As the name indicates, it is a flow diagram and is cumulatively represented. It gives insight into how many items are completed, how many items are remaining, and where the bottlenecks are in the process flow.

In the CFD below, I’ve taken the cumulative diagram for the number of issues coming to the development team on a weekly basis. There are three workflow states: “TODO,” “DOING,” and “DONE.”

Let’s interpret the diagram. Obviously the TODO items are getting added up at a faster rate, whereas the DOING and DONE are not able to catch up. TODO items in the graph are getting widening, and just below that, the DOING flow state is shown as narrower. This means that the bottleneck is in the DOING flow state. Also, the team is not able to move the DONE items well, either. From a technical standpoint, it may suggest that the items taken on may need to be broken up, or it may be possible that the team is unable to deliver on the issues taken up. 

To understand more on how a CFD can help in finding the bottlenecks, you can refer the below video [duration: 03m:39s]. It's taken from ACP Live Lessons, Guaranteed Pass course. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.


With these basics, let's check our project scenario. 

Our Project Scenario
Our project is that of house renovation work, which is being done within the Kanban framework. There are a number of work items to be completed in the backlog, some in progress, and some done, as shown below in the Gantt Chart view.

               

We have planned for the capacity available for the team; however, some of the items are not planned at all.  This can also be seen in the Task Board view (or the Backlog Board) view by going to View tab > Task Views > Task Board > Task Board command.
 
As shown in the above figure:

  • A couple of work items are in “Done” and “In Progress” states
  • One work item is in “Next up” state. 
  • A number of items are in the Kanban Backlog state.

The project’s Status Date has been set for Monday, September 19, 2022, which is one week ahead of the Project’s start date. For this scenario, we are going to build our cumulative flow diagram from scratch.

Building a Cumulative Flow Diagram
To create a CFD, first we have to go to the Report tab > View Reports group > New Report command and choose Blank report. The dialog box opens, and the report named, Kanban Cumulative Task Flow Report, as shown below. 



Kanban Cumulative Task Flow Report
To create the first-cut of the CFD, we go to Report tools > Insert > Chart command and insert an Area chart.
 

As you insert the chart, you will have your first view of a cumulative flow diagram with two fields:

  • Remaining Actual Tasks shows actual tasks remaining over the timeline of the project and is highlighted with a blue color. 
  • Remaining Tasks shows tasks remaining over the timeline of the project and is highlighted in an orange color.

This is depicted below with the number of tasks in the Y-axis and the timeline by date in the X-axis. 


Next, we are going to customize this chart to provide more clarity and understanding.

Customizing a Cumulative Flow Diagram

To customize the chart, I’ll enlarge the chart area, add the data labels for both Remaining Actual Tasks and Remaining Task fields, and apply associated color coding to have more visibility. You can learn how to do such steps in this article on Sprint Burndown and Burnup Charts.

After you customize the chart, it’ll be as shown below. 


Note:
  • Data labels have been added for both Remaining Actual Tasks and Remaining Task fields.
  • Data labels have been formatted for both these fields, with light orange and light blue colors, respectively.
  • The Remaining Tasks start with a value of twelve and go down to zero when the project ends.
  • The Remaining Actual Tasks start with a value of twelve and go down to ten as on the Status Date, which we have set earlier.

Now, the main part is the analysis of this data according to the Status Date:

  • The Remaining Tasks are eight, whereas the Remaining Actual Tasks are ten.
  • It means we are not actually completing tasks as we have expected or planned.
  • We can see that we are somewhat behind our planned progress.

While this CFD shows the cumulative task flow report and informs on the progress of the tasks, it doesn’t inform on what is happening at the board level. In the earlier part of the article, I stated, that with CFD, we can find out where the bottleneck is in our workflow. We need to find out where the bottleneck is at the board level.

For that, we will use another cumulative flow diagram. There can be a number of variants, but we will focus on task workflow across the column states of the Kanban Board.

Cumulative Flow Diagram – Board Status
To change the above CFD into a chart with Board Status, we have to apply the built-in grouping available in MS Project: Board Status.

We can rename this report in the Organizer by going to Report tools > Design tab > Report group and using the Manage command, or we can create a new CFD report entirely. Let’s create a new report and following the previously mentioned steps. The new “Kanban Cumulative Flow – Board Status Report” is shown below:

 
To create this report, we had to apply the “Board Status” built-in group. This can be done by going to the Field List command pane (as you select the chart area) and changing the Group By setting to Board Status (under Tasks). It’s highlighted in the figure.
Next, I’ll customize this chart by adding, formatting, and adjusting the data labels, etc. See below.

Let’s interpret the above figure, as of the Status Date of September 19, 2022:

  • The work items in the “Done” board state (at the bottom of the chart) are progressing properly.
  • The work items in the “In Progress” board state (just above the “Done” state) are also on track.
  • The work items in the “Kanban Backlog” board state are not moving as expected.
    • For this board state, the Remaining Tasks are highlighted in light blue, and the Remaining Actual Tasks are highlighted in green.
    • As on the Status Date, the Remaining Tasks are seven, but the Remaining Actual Tasks are five in number.

Looking at the above CFD, one can say that movement of work items is not happening from the “Kanban Backlog” state to the “Next up” state. The “Next Up” board state is also having a narrower band. Hence, the bottleneck is there.

There can be many possible reasons for it. A few are listed below:

  • Perhaps the team is behind on analysis to be done before moving the tasks from the “Kanban Backlog” state to the “Next up” state.
  • Maybe the team has been occupied by some other work, hence the items from the “Kanban Backlog” state are not being moved out faster.
This has to be analyzed by the project manager (PM), the Kanban Flow Master, or whoever is in a similar role. Kanban explicitly doesn’t prescribe a particular role, but indicates respect the current roles, responsibilities, and titles.

Determining the ‘Work in Progress’
Another advantage of Kanban CFD is the ability to determine the work in progress (WIP) for the project. This is in-line with another fundamental aspect of Kanban: Limit the work progress.
Let’s do a little bit more customization for the above chart by keeping only the Remaining Actual Tasks in the view. I’ll also change the date range from project Start Date to Status Date below: 


As shown, we can now quickly determine the total number of work items in progress:
  • Done state = 0
  • In progress state = 2
  • Next up state = 1
  • Kanban Backlog state = 7
Hence, the following is true:

WIP = 0 + 2 + 1 + 7= 10

Kanban emphasizes limiting this work progress for the purpose of smoothing the process flow. The WIP limit is usually driven by the organization’s policy and can be adjusted for the project under consideration.

Demonstration and Analysis
To demonstrate the charts that we just created and analyzed, take a look at the below video [duration: 10m: 37s], which I’ve prepared in support of this article. The content of the video is from my course, Mastering MS Project 2019 Agile



Conclusion
As noted earlier, the main purpose of using a Kanban cumulative flow diagram is its assistance in managing the flow of work. Unlike Scrum, where you have Sprints, in Kanban, flow is emphasized. A CFD also helps in visualizing the workflow, understanding the work in progress, and identifying necessary process policies.
One can also use a cumulative flow diagram to analyze other Kanban metrics, such as:

  • Cycle time
  • Lead time
  • Response time
  • Little’s law, etc.

Remember to be judicious while using cumulative diagrams. For example, it does not inform how big or small the tasks are. Also, I’ve seen Kanban practitioners using the scale in X-axis on days when a high number of issues or work items are being worked upon. If you do that, you won’t get any value out of it. Another scenario is working with Hybrid-Agile projects. Some practitioners create CFDs for the entire project, which gives no value. You need to customize your CFDs only for the work items, which are pulled-based and just-in-time with an on-demand delivery pattern.

I hope that this article has given you have a fair understanding on how to work with cumulative flow diagrams within MS Project. Your comments are welcome below.

--

This article was first published by MPUG.com on 8th March, 2022. This is an updated version.


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

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

[3] Online Course: PMI-ACP Live Lessons, Guaranteed Pass, by Satya Narayan Dash

[4] e-Book: I Want To Be A PMI-ACP, Second Edition, by Satya Narayan Dash