Sunday, November 28, 2021

Certified Hybrid-Agile Master with MS Project Online Course


I’m pleased to announce the availability of the Certified Hybrid-Agile Master Online Course for Agile practitioners and Management professionals:


It’s a complete video course on Hybrid-Agile Management with both theory and practical. Certified Hybrid-Agile Master course is an in-depth, hands-on, practical-oriented Certification Course and literally, only such course, worldwide. It also comes with full money back guarantee. 

While Agile practitioners use a large number of stand-alone frameworks such as Scrum or Kanban, many organizations execute their projects with a Hybrid-Approach. Multiple trends on various Agile frameworks inform this reality of Hybrid-Agile. In fact, some reports inform that usage of Hybrid-Agile is more than 80%!

A Hybrid-Agile approach combines two or more Agile and Non-Agile approaches. A Hybrid-Agile approach also follows real-life. Taking an example, no one takes the same prescribed meal (like a prescribed framework) every day! You mix and match the content of your meal based on your appetite, health-condition, and availability. Similarly, many organizations follow Hybrid-Agile approaches, which best meet their project requirements, project type, complexity and associated deliverables.

This course is highly needed by Agile practitioners as Hybrid-Agile projects are quite advanced, complex, and many times difficult to manage. With this course, you will know:

  • Hybrid-Scrum Management
  • Hybrid-Kanban Management
  • Hybrid-ScrumBan Management

You learn and work with a number of foundational as well as advanced concepts in Hybrid-Agile Management

  • Building a variety of Hybrid-Agile projects
  • Adjustment and tracking Hybrid-Agile projects
  • Baselining and Baseline Management in Hybrid-Agile
  • Earned Value Reporting in Hybrid-Agile
  • Hybrid-Scrum Burndown/Burnup charts (for Scrum as well Traditional)
  • Various Histogram and Pie Charts
  • Hybrid-Kanban Cumulative Flow Diagram (CFD) 
  • Closing Hybrid-Agile projects

With this course, you will also have an End Course Exam. On clearing the exam, you get the Certified Hybrid-Agile Master credential, indicating your mastery over hands-on Hybrid-Agile Management. 

Top 10 Features: Certified Hybrid-Agile Master

  1. Total Video Duration: 14+ hours (14h 21m 40s)
  2. Number of Videos: 138
  3. Number of Lessons: 10 (+1)
  4. Total Exercises (Practical): 100+
  5. End-course exam and credential as a Certified Hybrid-Agile Master.
  6. In depth understanding of Hybrid Scrum, Hybrid Kanban, and Hybrid ScrumBan.
  7. Ability to apply the concepts with the Hands-On tool of MS Project Agile.
  8. Generate various reports such as Burndown/Burnup Chart, CFDs, Hybrid Sprint Reports, Histograms and Pie Charts, Earned Value reports, among many others.
  9. A large number of exercise and solutions files (over 100), which you can download, use and practice.
  10. A large number of tips and tricks points to know throughout the course.

Course Breakdown: Certified Hybrid-Agile Master

  • Lesson 1 – Welcome (7 videos): 17m 56s [17 minutes 56 seconds]
  • Lesson 2 – Understanding Hybrid Project (15 videos): 59m 43s
  • Lesson 3 – Hybrid Project with MS Project (15 videos): 1h 49m 27s
  • Lesson 4 – Hybrid-Scrum Project (27 videos): 3h 33m 16s
  • Lesson 5 – Hybrid-Scrum Project Reporting (16 videos): 1h 47m 07s
  • Lesson 6 – Hybrid-Kanban Project (24 videos): 2h 36m 16s
  • Lesson 7 – Hybrid-Kanban Project Reporting (10 videos): 1h 11m 26s
  • Lesson 8 – Hybrid-ScrumBan Project (15 videos): 1h 23m 01s
  • Lesson 9 – Hybrid-ScrumBan Project Reporting (7 videos): 40m 39s
  • Lesson 10 - Conclusion (2 videos): 4m 39s
  • All Exercises (Certified Hybrid-Agile Master)

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

What is the Certification offered by this Course?

This course comes with an end-exam with a set of questions, which covers both theory and practical of Hybrid-Agile Management. To clear the exam, you need at least 70% score. 

With completion of the course and clearing of the end course exam, you will receive the unique credential: Certified Hybrid-Agile Master with MS Project. 

Unlike many courses available in the world today, this course has in-depth theory and practical with an Agile Management software tool. Hence, you can apply the theoretical understanding in a hands-on manner. Your Certified Hybrid-Agile Master credential demonstrates your knowledge of Hybrid-Agile theory and practical. 

What is Full Money Back Guarantee for this Course?

There are no little tricks, such as – “terms and conditions apply”, “** conditions apply”, “guarantee not applicable if you have seen 15% of the course”, “give at least one attempt or we will refund your money” etc., as you would have seen in many places. What you see and read here is what you get.

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

  • Theory Used – Hybrid-Agile Management combining Traditional, Scrum and Kanban
  • Software Used – MS Project 2019 Online Desktop Client 
  • Price 
    $95 USD / Rs 6,649  (3 months access)
    $159 USD / Rs 11,149  (6 months access)
    Extension is also available. Price calculation will be pro-rata.
  • Payment –
    (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 to get account the details.
  • Available since – November, 2021
  • Primary Format – Video
  • Status – Available
    (accessible via laptop/desktop)

Detailed Course Breakdown

The detailed course breakdown is shown below. It details hours of learning, number of videos and various exercise details. You can scroll to see the full content. 

If you want to buy this course or have any question, please send an email to 

Wednesday, November 24, 2021

Prioritization Techniques in Agile for Product Managers

Let’s consider two real-world scenarios. In one, a product manager is asked to work on the top priority items in his project’s product backlog for an upcoming iteration. The product manager replies, “It can’t be done because the business executives have set everything to be of top priority.”

In a second situation, a few stakeholders didn’t want to proceed with a compliance requirement, which had a time limit. Rather, they wanted to pursue another feature expected to bring more value. In this case, the product manager said, “We can make that feature happen in place of the compliance one, except that the CEO has to spend some time in jail, because of non-compliance!”

Now, in the first situation, the product manager has been forced to address all items, because all are high-priority. Do you think anything would be delivered properly at all? In the second one, if the CEO goes to jail, do you think the product manager could in any way keep his or her job?

How could these situations be properly addressed?

If you are thinking that we need prioritization or the right prioritization schemes, you are correct, and this will be our topic of discussion in this article. We will focus on prioritizing items in the Product Backlog, which is a key element of Agile development.

The product backlog (PB) is an ordered list of user requirements, typically owned by the Product Owner or Product Manager, who is the proxy for the customer. Do note that Agile practitioners use the term ordered for product backlog items (PBI) in place of prioritized. Prioritization, after all, is a form of ordering; however, going forward I’ll use these terms interchangeably.

Before we cover various techniques for prioritization, let’s understand the essential qualities of a Product Backlog.

A DEEP Product Backlog

The product backlog is characterized by four qualities, i.e., the PBIs in the PB are detailed appropriately, estimated, emergent in nature, and prioritized. The acronym for it is DEEP.

  • Detailed appropriately: It means the high priority items in the product backlog are listed in more detail (or fine-grained) as compared to the low priority items, which are coarse-grained.
  • Estimated: The PBIs are estimated. The high priority items can be estimated in story points, ideal days, or any other estimate, whereas the low priority items can be in the form of epics.
  • Emergent: The product backlog is not a static artifact. When new items are discovered, they are added to the bottom of the product backlog.
  • Prioritized: The items in the product backlog are prioritized, with the highest priority PBIs on top of the product backlog (these items are pulled to be executed in the upcoming iteration). The prioritization of the items is generally done with respect to the value delivered, though there can be other factors as well. We will see more on this shortly. 

As you may have noticed, one of the qualities for the PB is that the items are prioritized. However, not all PBIs must be prioritized, rather you should do it for some immediate Sprints or iterations. This also compliments the first quality for the product backlog, (i.e., detailed appropriately).

In fact, the backlog follows the concept of rolling wave planning, (i.e., we plan for few immediate iterations in detail, whereas the future iterations will at a higher-level). This has been illustrated in the below figure. 

Earlier, I noted prioritization occurs generally with respect to the value delivered, but there can be other factors at play, as well. Let’s take a look at some of the other factors for prioritization now. 

Factors in Prioritization

Below is a list of factors which help to prioritize:

  • (Business) Value of having the features
  • Cost of developing the features
  • Compliance, i.e., set of rules considered safe to be followed such as regulations
  • Knowledge gain, which tells to what extent the team will gain them while working on features
  • Amount of risk removed by having the features
  • Resources available because a particular backlog item may require specialized resources (human or physical) or resource with domain knowledge
  • Dependencies among the features or PBIs

These prioritization factors are depicted in the below figure. 

With these basics in mind, let’s consider some of the techniques used in prioritization. 

Various Techniques for Prioritization

Simple Scheme

Here we label feature items as “Priority 1,” “Priority 2,” “Priority 3,” and so on, or “High,” “Medium,” and “Low” items. One of the drawbacks in this scheme is that business executives want everything to be P1 or high priority types.

Monopoly Money

The sponsors of a project are given an equal amount of money for the project budget, and then asked to distribute it amongst system features. This is effective only when limited to prioritizing business features.

100 Point Method

This is a scenario where each stakeholder is given 100 points that he or she can use to vote for the most important requirements. How points are distributed is up to them – 30 for one item, 20 for another, or even all 100 points for a single item. This method was first developed by Dean Leffingwell et al.

Kano Analysis

Kano Analysis (or the Kano model) informs regarding product features which are perceived to be most important to customers. This method was created by Dr. Noriaki Kano and focuses on differentiating product features, as opposed to focusing initially on customer needs. This analysis involves two dimensions:

  • On X – axis: The product feature presence is listed.
  • On Y – axis: Customer satisfaction is listed. 

The features are divided into three levels, which we will understand by considering an example of a phone.

Must-have or Mandatory features:

These are must have features and mandatory. For example, basic functions of a mobile phone include switching on/off, making calls, receiving calls, sending/receiving text messages, etc.  These are threshold functions, which are basic and necessary to sell the product. Without these, the product is useless. However, beyond a point, on these functions, customer satisfaction does not go up – rather, as shown above, it goes down.

Performance or Linear features:

Here the motto is “the more the better.” The higher the number of performance functions leads to higher customer satisfaction. For example, if the phone is slimmer, and it boots-up quickly, then we have more satisfied customers. The price of the product is related to the linear features, but these are not differentiators to sell the product. For that, we need exciters and delighters.

Exciters and Delighters:

These are related to hidden customer needs, or things that the customer is not even aware of. These provide a unique selling point (USP) for the product; however, absence of these doesn’t necessarily mean that the customer won’t be satisfied. For example, having a face recognition feature in a phone that allows it to unlock. Nevertheless, the presence of such features can lead to premium pricing of the product.

There can also be other levels such as indifferent, which tells us that the feature presence is irrelevant to the customers’ satisfaction, and reverse (i.e., the presence of such a feature will reduce customer satisfaction). 


MoSCoW is another technique for prioritization. The letters stand for:

  • M – Must Have
  • S – Should Have
  • C – Could Have
  • W – Won’t Have this time (but would like to have!)

The “Os” are added for easy memorization. The idea in the MoSCoW technique is that instead of prioritizing the requirements as high, medium, or low, priorities are specific.

  • Must Have: Minimum Usable Subset (MUS) of features which the project must deliver. The best way to find a must have feature is to ask the question, “What happens if this feature is not available?” If the answer is “cancel the project,” then we have a “must have” feature on our plate.
  • Should Have: These are important, but not vital requirements. If you leave them out, it will be painful, but the solution is still viable. If you skip these, you may need some kind of workaround for it.
  • Could Have: These are wanted or desirable features, but less important. A “Should Have” may be differentiated from a “Could Have” by reviewing the degree of pain caused by the requirement not being met, in terms of business value or number of people affected.
  • Won’t Have this time: These are features which your team has agreed on having in the long run, but will not deliver in this release or iteration. 

Cost of Delay Divided by Duration (CD3)

The CD3 method was developed Donald Reinertsen. The name CD3 comes from 3Ds in “Cost of Delay Divided by Duration.” Cost of delay informs what the penalty of cost of delaying these features. This is expressed in a Money/Time format (i.e., $400/week or $150/day). Next, it is divided by the duration or time that will take to build the feature. The feature with the highest score is tackled first or will have the highest priority.

One frequent question I receive is how to model these prioritization schemes with the help of software tools. Let’s work through an example using MS Project software. 

Prioritization of Backlog with MS Project 2019 Agile

MS Project 2019 supports both Scrum and Kanban. We will use Scrum framework to understand how the backlog items are prioritized, and we will follow the following steps.

Step – 1: Define a Prioritization Scheme

Let’s take a simple scheme, which, as the name tells us, is not only simple, but also widely used. We need to create a custom field. In our case, I’ve created a custom text field “PBI Priority”, which is shown below: 

Next, in the look-up table, highlighted in the above figure, you have the option of defining the priority level – high, medium, low, or undefined. The “undefined” level will correlate to the PBI when it’s newly entered into the backlog. 

As shown above, we have four levels in the list with the “Undefined” one set as the default.

Step – 2: Enter the Product Backlog Items

You can enter the backlog items into the “No Sprints” column, which is for the product backlog in the Sprint Planning Board view. The items should be estimated, and you can use story points, ideal days, or any other format as needed. This is depicted below. 

We have items listed with the default PBI priority “undefined” shown for each item.

Step – 3: Assign Priorities to the PBIs

Next, we will assign the priorities, which, is again, quite simple and straightforward. To do so, I’m using the Sprint Planning Sheet view and choosing the priority for each PBI in the “PBI Priority” field. 

Step – 4: Reorder the Product Backlog

The final step is to reorder the product backlog items. This is done by simply dragging and dropping the cards or the PBIs in the backlog, under the Sprint Planning Board view. As you reorder, the high priority items are moved to the top of the backlog, whereas the low priority items will appear towards the bottom. This is depicted below. 

If you are using another prioritization scheme associated with a formula, you can define the formula and use the look-up table to set the priorities for the PBIs. 

Prioritization of Backlog with MS Project for the Web

Microsoft recently released a new version of Project, Microsoft Project for the Web. With this app or service, you can also create a backlog of items and order the items by dragging and dropping the cards in the Board view. 

As shown above, we have a product backlog where the PBIs are listed and ordered. These items will then be subsequently pulled into various Sprints. One great advantage of MS Project for the Web is that you can drag and drop and in turn, change the dependencies. This can be done in the Timeline view, which is shown in the figure below: 

I hope you now better understand the various product prioritization techniques and how to apply them with the help of a software tool. Though product prioritization is the job of a product owner or product manager with inputs from team members, it is equally useful to know if you are working as a project manager, scrum master, Kanban flow master, or in any other similar kind of role. 


This article was first published by on 7th January, 2020.


[1] I Want To Be A PMI-ACP: The Plain and Simple Way, by Satya Narayan Dash

[2] Microsoft Project Live Lessons with Money Back Guarantee, by Satya Narayan Dash.

[3] Scrum Product Ownership: Balancing Value from the Inside Out, by Robert Galen

[4] Agile Product Management with Scrum: Creating Products that Customers Love, by Roman Pichler

[5] Documentation for Microsoft Project for the Web, by Microsoft Corporation.

Saturday, November 20, 2021

Retrospectives and Intraspectives for Agile Practitioners

Two woodcutters were assigned to chop wood in a forest. Both formed a team and started early and earnestly. Although working a distance from each other, they felt the competition to produce the best results.

On that first day, the first woodcutter heard his counterpart stop cutting before the day was really finished. He was surprised, but continued none-the-less. In the next few days, a similar thing happened. A couple of weeks passed. The first woodcutter paid a visit to the second one, confidently thinking that he has cut more wood since he had been working such full, long days. He was taken aback seeing that his counterpart has almost completed twice as much work. He asked, “How is that possible? I never stopped or took a rest, whereas you stopped many times!” The second woodcutter replied, “Yes, but I didn’t actually stop. Rather, I sharpened my axe, so that I could continue cutting better for the next day, the next week, and the weeks ahead.”

Perhaps many of us know this story of the two woodcutters and the key takeaway: “sharpen the axe once in a while and you get better results.” Stephen R. Covey slightly reworded the moral of the story eloquently in his book “The 7 Habits of Highly Effective People” by saying, “Sharpen the saw.

Let’s apply this by thinking of a team of Agile practitioners working on a software product. The team has a number of generalizing specialists, who have skills spanning across coding, testing, integration, and deployment among others. They are cutting code instead of cutting wood, are testing the soundness of code instead of the solidness of wood, and so on.

Would you ask them to continue working week after week or month after month without ever sharpening their tools? I guess not.

Retrospectives and intraspectives in Agile development do exactly that. They sharpen the saw, or ask us to reflect, rethink, and act with renewed vigor. They provide a better understanding and also help us to work sustainably over a long period. 


The importance of taking the time for retrospection comes from one of the 12 core principles of the Agile Manifesto.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In Agile, frequent retrospection is done in order to continually improve the effectiveness of the team, project, and organization. The retrospective process consists of two words:

  • Retro – meaning recent past, and
  • Perspective – meaning the way of looking at things.

Hence, you can say that the retrospective is about looking back or dealing with past events or situations for the purpose of improving in the future. You can define the retrospective process as:

A recurring workshop in which the team looks back on their work over a period, reflects upon it, and learns. The team applies this learning in future work to improve people, processes, and products.

One of the widely used iteration-based Agile frameworks is Scrum where every iteration is known as a Sprint. There is a Sprint Retrospective at the end of every Sprint, and it’s an opportunity for the team to inspect itself and create a plan for further improvements. The plan is preferably acted-upon in the next Sprint. Retrospectives are also applicable in flow based Lean-Agile frameworks, e.g., Kanban, where you can have retrospectives on-demand. 

Types of Retrospectives

In iteration-based Agile development, a project is usually divided into releases and each release into various iterations. Hence, for Agile practitioners, there are three types of retrospectives:

  • An Iteration Retrospective: Usually focused on the team involved in the iteration.
  • A Release Retrospective: A wider perspective because it may involve other people in the organization who have contributed to the release, but are not part of the core team.
  • A Project Retrospective: Also has a wider perspective, and is usually from an organizational point of view.

Retrospectives can happen in the following cases:

  • When the team ships something. In a flow-based Agile (like the Kanban method), a release doesn’t happen during a specific time period. It can happen at any time.
  • When more than a few weeks have passed since the last retrospective. Again, in a flow-based Agile process, there is no specific time a retrospective can happen. You can decide in such cases.
  • When the team is stuck (i.e., the work items are not flowing through the team).
  • When the team reaches a milestone. 

Conducting Retrospectives

A retrospective is not a post-mortem meeting, nor should it be a dissection on what events happened wrongly or why. A retrospective should also not be a witch-hunt meeting to put blame on someone or some group. The key to a constructive successful retrospective is for all participants to adhere to the Retrospective Prime Directive, as noted by Norman Kerth, which says:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Four Key Questions

Considering the prime directive, there are four key questions in a retrospective, which can also be used when creating your meeting agenda:

  • What did we do well, that if we don’t discuss we might forget?
    (or what is going well?)
  • What did we learn?
  • What should we do differently next time?
  • What still puzzles us?

Look at the wording closely. We aren’t asking what went wrong, rather as the third question goes, we are asking what should be done differently next time.

Five Steps in a Retrospective

A retrospective, as noted, can happen as part of both iteration-based and flow-based Agile frameworks. A retrospective is a process, and it goes through a series of steps. See the figure below. It’s depicts a two-hour (120 minute) retrospective with time spread across the five steps of:

  • Step 1 – Set the Stage
  • Step 2 – Gather the Data
  • Step 3 – Generate the Insights
  • Step 4 – Decide What To Do
  • Step 5 – Close the Retrospective

Let’s understand these steps.

Step 1: Set the Stage

Here the time box (how much time), goal (what you are going to do), approach (how you are going to do it), and work agreements or ground rules are set. If any particular Agile method is used, then the values of that method are announced. The principle of “Every voice and early” is followed, i.e., everyone should speak, and they should speak early. If they don’t speak early, then they may not speak at all!

Step 2: Gather Data

Once the stage has been set, the next step is to gather data. Start with hard data such as metrics, events that’ve happened, or stories completed. Create a visual record having events, story completion, date, etc. The visual is very powerful. Data doesn’t have emotions; therefore, ensure that you bring feelings into the data by asking questions such as, “When were the participants excited to come to work?”

Step 3: Generate Insights

After you have gathered the data, it’s time to evaluate, analyze the data, and provide insights. This step tells the “why” i.e., we generate meaningful insights from the data collected in the previous step. These insights help the team to work more effectively and efficiently – the main goal in any retrospective.

Step 4: Decide What to Do

This step reveals the “what to do” part or the planning part. If you have a long list of decision action items, choose a few, which the team can commit to doing – preferably in the next one or two iterations. A good way to have the action items implemented is to create story cards or backlog items and have them available in the product backlog. Ensure that you assign action items because it drives commitment.

Step 5: Close the Retrospective

In this step, you close the retrospective. When you close the retrospective, don’t forget to appreciate your team for the hard work done during the iteration (or release or project) and during the retrospective.

Retrospective Techniques

In each of these above steps, a number of techniques can be used. We will discuss a few of them. 

Techniques to “Set the Stage”

1) Check in: In this technique, we hope that people put aside their concerns and participate in the retrospective articulating what they want from it. The retrospective leader asks only one question and each person answers in round robin fashion. The answers are usually in one or two words or a short phrase. Example questions can be:

“In a word or two, what you expect from the retrospective?” Or “What is one thing in your mind as we begin the retrospective?”

2) Explorer, Shopper, Vacationers, Prisoners (ESVP) Quiz: Let’s first understand what the letters in ESVP stand for.

  • Explorers: Someone who is eager to know new ideas and insights.
  • Shopper: The participant looks over all information, but is happy to go home with one useful new idea.
  • Vacationers: The participant is not interested and happy to be left out.
  • Prisoners: Someone who thinks that he or she has been forced to attend the meeting and should be doing something else.

In this exercise, each retrospective participant anonymously writes sown his or her position and puts it on a slip of paper or index card. Next, the leader takes the responses and put them into a histogram or a check sheet.

After the results have been collected, you should tear up the cards so that no one is worried about being tracked with handwriting analysis! With this information, you will have a good idea of how your audience feels about the retrospective. This exercise informs about the participants’ attitudes in particular.

Other techniques that can be used in the step of setting the stage are: Focus on/focus off, working agreements, or ground rules. 

Techniques to “Gather Data”

1) Timeline: A timeline is used to stimulate memories of what happened in the time period that just passed. The retrospective participants write down memorable and meaningful events on sticky notes and paste them in chronological order on a board. A sample example is shown below, which in this case, is for an iteration.


2) Mad Sad Glad: Here you have three posters labeled – “Mad,” “Sad,” and “Glad.” You can also have color-coded cards or sticky notes. For example: red for mad, yellow for sad, and green for glad.

The team members then put the color-coded cards on the labelled posters and describe times during the project when they felt mad, sad, or glad. This exercise gets the “feeling facts” out on the table.

Other techniques that can be used in this step are: triple nickels, color coded dots, locate strengths, team radar, or like to like. 

Techniques to “Generate Insights”

1) Force Field Analysis: This technique was originally used in a change management context (and also in risk management), but it can be adapted for retrospectives. Here, the team defines a desired state they want to achieve. Then, identifies the following:

  • Driving forces (“forces of change”), which affects the desired state positively.
  • Restraining forces (“forces against change”), which affect the desired state negatively.
  • Factors that can influence reaching the desired state—either by increasing the strength of a supporting factor or by reducing the strength of an inhibiting one.

Utilize a white board and markers with this analytical technique. 

2) Learning Matrix: In this case, participants look at the data generated from four perspectives by brainstorming on them quickly. This is a good technique to use if you are pressed for time. The four perspectives can be put on a flip-chart or white board, each in a quadrant, as depicted in the figure below. 

Brainstorming, Ishikawa diagram, patterns and shifts, and the five whys are some of the other techniques that can be used in this step. 

Techniques to “Decide What to Do”

1) Short Objects: This technique helps to discover differing perspectives on what the team members should or should not do, or should do more or less of. The team brainstorms and put their perspectives on three or two posters or flip charts. The titles of each could be:

  • Same as/More of/Less of (SAMOLO)
  • Stop Doing/Start Doing/Keep Doing (StoStaKee)
  • Keep/Drop/Add
  • What Worked Well/Do Differently Next Time (WWWDD)
  • Smiley/Frowny 

2) Prioritize with Dots: This technique is used to check how the team prioritizes a long list of changes, ideas, issues, or proposals. Here each participant is given 10 dots to be used across the issues. A scale, such as shown in the following bullet points, can be applied.

  • Priority 1 issues receive four dots.
  • Priority 2 issues receive three dots.
  • Priority 3 issues receives two dots.
  • Priority 4 issues received one dot.

The issues that have the most dots are chosen, and those should be focused on.

Other techniques that can be used in this step are: retrospective planning game, SMART (speciļ¬c, measurable, attainable, relevant, and timely) goals, and circle of questions. 

Techniques to “Close the Retrospective”

1) +/Delta (Plus/Delta): This technique is used to retrospect on the ongoing retrospective and identify areas of strength and areas needing improvement. It starts with drawing a “T” on a flipchart or white board, divided the space into two parts: “+” and “delta.” The items that the team should do more of should be listed under “+” and ones that can be changed by the next retrospective are put under “delta,” which is the Greek alphabet meaning “change.”


2) Return On Time Invested (ROTI):

This technique generates feedback on the retrospective process itself and determines the effectiveness of the retrospective session from team members’ perspectives, by asking if the participants believe their time was spent well. You can use a scale rating system (“0” representing a lost cause and “5” indicating a very high return or the highest ROTI).

Other techniques that can be used in this step are: appreciation, temperature reading, helped, hindered, hypothesis (HHH), etc.



The term, intraspective, consists of two words – intra meaning within (or insider) and perspective meaning the way of looking at things. Hence, intraspective is defined as an inspection or reflection for the team, within an iteration. Like a retrospective, an intraspective is a reflecting practice; however, unlike retrospective, it’s often preceded by an event that didn’t go well. Unlike the retrospective process, which can happen at points throughout the project, at the time of a release, or at the project level, the intraspective process happens within an iteration.

Let’s take an example with Scrum to understand. Post daily scrum, the Scrum Master noticed or heard something about consistent failure in release builds due to frequent configuration changes in the build scripts. The Scrum Master calls for an intraspective meeting on it to figure out if change is needed on the way team is modifying build scripts.

In iteration-based Agile methodology, the introspection meeting is, in essence, a retrospective within an iteration. The need for such can also occur in a flow-based Agile project. The purpose of an intraspective is to discuss a particular issue, event, or activity in order to determine if any change(s) are needed in the team’s practices.

The main goals of an intraspective is to inspect and adapt – the two key foundations of empiricism. Intraspectives happens on an ad-hoc or on-demand basis. It also helps in building a self-organizing team. 

Key Points about Retrospectives

Irrespective of the type of retrospective or techniques used in a retrospective, below are a few key points to note while conducting one.

Item #1: Everyone should participate: If you remember the “setting the stage” step, we first discussed a check-in, which asked for everyone’s participation. When there is buy-in from the team as a whole, it is easier to proceed with further actions and improvements.

Item #2: Choose two techniques for each step (one short and one long). There can be many techniques or activities in the five steps of a retrospective. Preferably have one short and one long for each step, and you may altogether skip the shorter one, if you lack time.

Item #3: The Product Owner (PO) should be present: The PO is a core part of the team and should be present at retrospective meetings. As I interact with Agile practitioners, lack of the PO’s involvement has been noted by many as the most pressing issue. It’s important that the owner is a part of reflection discussions.

Item #4: For a longer retrospective, consider breaks. If the retrospective is more than two hours, ensure you have break on your agenda, even if it is just 10 minutes. Schedule breaks when there is a logical breaking point, when the energy level of the team drops, or when team members ask for one.

Item #5: Retrospective is not a post-mortem session. Any meeting that turns into dissecting issues or finger-pointing is futile. The retrospective should never be a whining session, rather an opportunity to contribute, reflect, and plan actions. Remember the story of the woodcutters and the retrospective prime directive, noted earlier.


This article was first published by on 15th October, 2019.



[1] I Want To Be An ACP – The Plain and Simple Way, by Satya Narayan Dash

[2] Agile Retrospectives – Making Good Teams Great by Esther Derby, Diana Larsen, and Ken Schwaber

[3] Agile Practice Guide, by Project Management Institute (PMI)