Sunday, June 15, 2025

Scrum at Scale with CIPSA: The Principal Scrum Master (PSM) – What It Is and What It’s Not!

 

In the CIPSA Scrum Framework, in addition to the primary role of Chief Product Owner, we also have the Principal Scrum Master (PSM). This role is necessary to have Scrum at Scale with CIPSA. Unlike the Individual Teams’ Scrum Masters, the role and responsibilities of the PSM are different. It’s a very important role to have in order to succeed at Scale. 

In this post, we will explore more on the Principal Scrum Master role as there are a number of misconceptions and misunderstandings. It’s presented in the form of what it is and what is not, to provide greater clarity.  

The following are some of them. To read all articles of this series use this link: 

What It's and What It's Not series for CIPSA


Principal Scrum Master – What It Is and What It’s Not

1. Not Manager, but Leader: The Principal Scrum Master is not the manager of the CIPSA team. The Principal Scrum is a true leader who serves the team and organization.

The Principal Scrum Master leads by serving, not managing. The PSM focuses on team and organizational needs.

2. Not Intra-Team, but Inter-Team: The Principal Scrum Master is not concerned about intra-team dependencies. The Principal Scrum Master focuses on inter-team dependencies.

Rather than resolving team dependencies which are internal, the Principal Scrum Master addresses coordination across multiple teams. The PSM manages dependencies that span beyond one individual Scrum Team.

3. Not Team Tracking, but Product Tracking: The Principal Scrum Master does not track the individual Team Increments. The Principal Scrum Master tracks the overall product work and progress.

The focus of a PSM isn't on individual Team Increments, but on the unified or Integrated Increment. This ensures the overall product progress aligns with strategic objectives.

4. Not Fragmented, but Unified: The Principal Scrum Master does not communicate like individual Team Scrum Masters. The Principal Scrum Master is the main communicator for and of the CIPSA Team.

The PSM provides a unified voice to upper management. Communication is consolidated through the Principal Scrum Master. This ensures alignment across teams rather than fragmented messaging from and for each Scrum team. 

The PSM is the main spokesperson for the CIPSA team.

5. Not Reporting, but Enabling: The Principal Scrum Master is not a chief-clerk or secretary responsible for reporting the status. The Principal Scrum Master enables progress for the entire CIPSA team.

The PSM don't just gather updates and report status for the CIPSA Scrum team. The PSM actively remove obstacles and facilitate progress. This role is about driving momentum, not about reporting status as chief-clerk.

6. Not Spot Checks, but Systemic Resolution: The Principal Scrum Master does not check for issues and impediments of individual teams. The Principal Scrum Master ensures that cross-team issues are addressed and cross-team impediments are removed.

Instead of isolated checks, the PSM drives solutions to broader, recurring impediments. It's also about issues impacting multiple teams. The approach taken by the PSM is proactive and system-wide.

7. Not a Replacement, but a Complement: The Principal Scrum Master does not replace the responsibilities of individual Scrum Masters. The Principal Scrum Master complements their efforts by coordinating cross-team work.

The Principal Scrum Master doesn't take over individual Scrum Masters’ roles. Many have this misconception! Instead, he or she coordinates and supports cross-team initiatives. 

The PSM complements, not replaces, the individual Team Scrum Master.

Summary Table – Principal Scrum Master 

For quick remembrance and recall, a summary table is shown below.  


Closing Remarks

It’s the PSM who ensures the CIPSA meta-events are conducted in a positive manner and are productive. Do remember that these meta-events are timeboxed. 

While going with Scrum at Scale with CIPSA, the key focus is on the CIPSA Integrated Increment. Ultimately, that’s artifact that matters! The PSM plays an indispensable role in having the Integrated Increment. See here.

  • Want to learn more with hands-on practical software tools?
  • Want to know how the PSM and CPO are assigned?
  • Want to visualize cross-team dependencies for the entire CIPSA team?
  • Want to assign resources for Scrum at scale?
  • Want to resolve overallocations for Scrum at scale?
  • . . .
  • . . .

Consider being a CIPSA professional. You will get the highest possible return on your investment. 


What It's and What It's Not Series:

All Articles in What It's and What It's Not - CIPSA

CIPSA Sample Videos and Questions:

[1] CIPSA Sample Video List (Choose a Video)
[2] CIPSA Video Playlist (Complete Playlist)





Wednesday, June 11, 2025

Agile and Artificial Intelligence (AI) – Three Cs of a User Story and Three Cs of a Prompt


Agile and Artificial Intelligence (AI) are not exactly cousins or twins. At a fundamental level, there are differences. Agile is about iterative and incremental development, whereas AI is about data-driven learning. Agile is about fast delivery, whereas AI is about fast learning, particularly considering the large language models (LLMs). 

In addition, Agile is about delivering value, whereas AI is extracting value from data. Agile revolves around user stories, whereas AI is mainly about data stories!

So, how does one compare and contrast Agile with AI?

In this article, we will explore more and we will learn through two building blocks of Agile and AI. For Agile, it’ll be the user stories or simply stories. For AI, on the other hand, it’ll be the prompts

We will start with the basics and then proceed to the three Cs of user stories and prompts. Prompt engineering is an emerging field in AI and indeed, there are job postings related to it, worldwide. Though a new engineering field, there are commonalities with the “Cs” of a use story, which will make prompts more understandable. 

So, let’s start with the basics.

What’s a Story in Agile?

A story replaces requirements in Agile development. I’ll define a story as follows:

"A story is a brief description of deliverable value to a stakeholder."

But you’d have definitely come across the concept of “User Story”. So, what’s that? A User Story is a story about a particular user. Yes, it’s that simple! For example, the user can be a:

  • a customer, 
  • a system administrator, 
  • a sales person, 
  • an employee, 
  • or any other. 

You can learn more about story and user story here.

What’s a Prompt in AI?

With prompts, an AI model generates a response. The better the prompt, the better the response. Again, I’ll define a prompt in simple terms as follows:

“A prompt is an input instruction to an AI model.”

That’s it! It’s basically an instruction given to an AI model, e.g., GenAI model. 

Now, like stories, there can be varieties of prompts such as Natural Language Prompts for natural language processing (NLP), System Prompts with predefined instructions or templates, which can be loaded into an AI model to generate concise and clear responses. 

Next, with these basics in mind, let’s dive deeper into the three Cs of stories and three Cs of prompt engineering.   

Three Cs in Agile Use Story (Scrum or Kanban)

The three Cs are actually for user stories, but can be applied to other types of stories. You can use them both in Scrum or Scrum at Scale (see here), and Kanban or Kanban at Scale (see here). The three Cs are:

Card: A card represents the user story’s intent. It can be on an index card, sticky note, or an electronic card. The most used one is a sticky note on a Scrum or Kanban board. This is the visible part of the three Cs.

Conversation: A conversation represents a promise of interaction. This interaction is between the developers and customer, or a proxy of the customer, e.g. the Product Owner.

Confirmation: A confirmation is the verification part of the story. It provides the acceptance criteria and it ensures that the story is properly and correctly implemented. 

A figurative representation of these three Cs in a user story is shown below. 


Three Cs of an AI Prompt

Here, the three Cs are actually for a Prompt, a key aspect in having right conversation with an AI tool, when generative AI is used. The three Cs are:

Clarity: The clarity part is about clear instructions given in the prompt to the AI-bot. A clear instruction helps the AI tool to understand the intent of the user. The instruction should be unambiguous. 

Context: The content part is about background information related to the instructions. It can be associated with a persona, a real-world figure or examples. This guides the AI prompt and actually, the model behind it. 

Constraint: The constraint part refers to the limitations put in the prompt. Constraints set the boundaries or the boundary conditions. The constraints can be with respect to length, format, style, or others.

A figurative representation of these three Cs in a prompt is shown below.

Can 'command' be a "C" for a prompt? No. Because the prompt itself is a command! Isn't it? This is what I wrote in the definition of a prompt in the beginning. In other words, the instruction itself is a command to the AI model.

Types of Stories in Agile 

In an article of Stories about Stories in Agile for Product Managers, I’ve informed about a number of stories with examples. You can read the full article here. At a high level, the types of stories are:

  • User Stories
  • Spike Stories
  • Architecturally Significant Stories
  • Analysis Stories
  • Infrastructure Stories

For each of the above types of examples are given, followed with exercise. You can try those. 

Types of Prompts in AI

Just as there are types of stories, there are also different types of prompts. The three Cs of stories can be applied to the types of stories and three Cs of prompts can be applied to types of prompts. 

For example, following can be the types of Prompts:

  • Zero-shot prompts,
  • Single-shot prompts,
  • Multi-shot prompts, 
  • Chain of Thought (CoT) prompts, among many others.

However, in this article, our focus is on the three Cs. So, let’s take some examples to understand the three Cs and three Cs of User Stories and Prompts.

Examples – Three Cs in a (User) Story

For a user story, as we just saw in the article, the 3 Cs are – card, conversation and confirmation. 

Card: Here is an example prompt written on a card. 

  • Incorrect way: “I want a search function.”
  • Correct Way: “As a home user, I want to search by water purifier product, so that I can find the right purifier.”

Conversation: Conversation happens between the developers and the customer. Here, the Product Owner (PO) acts as the proxy of the customer. One example conversation might look like this:

  • Developer: “Do we need to provide all water purifier product names or specific top selling products?”
  • PO: “Initially let’s make it brand specific.”
  • Developer: “Can you tell what are the brands we include?”
  • PO: “We can start with Brand ABC.”
  • Developer: “Should it be applicable to all interfaces – web, mobile and desktop?”
  • PO: “Let’s start with the web first.”

The conversation gets more and more refined as the conversation progresses. 

Confirmation: Confirmation is primarily about acceptance criteria.

Followings are some of the examples of acceptance criteria, assuming the story is really refined and can be done in one Release (as in Kanban) or Sprint (as in Scrum).

  • The water purifier items to be listed as the search function is executed.
  • At least three items from the same brand – Brand ABC – should be listed.
  • The items are both from regular and advertise items.
  • If no matching for the product item, then no a message of "no products found" should be displayed. 

Examples – Three Cs in a Prompt

For a prompt used on large language models (LLMs) in GenAI, as we know earlier, the three Cs are – clarity, context, and constraint

Let’s look at some examples showing both correct and incorrect prompts for each of the aforementioned Cs.

Clarity: Here is an example prompt with clarity. 

  • Incorrect Way: “Tell me about this article.”
  • Correct Way: “Summarize the following article in a few sentences.”

Context: Below is an example prompt with context, i.e., background information. 

  • Incorrect Way: “Give a summary of hybrid-agile management.” 
  • Correct Way: “Considering CHAMP certification from ManagementYogi, summarize the hybrid-agile model and management used in bulleted points.”

Constraint: Here is an example prompt with constraint, i.e., setting the boundaries. 

  • Incorrect Way: “Explain CIPSA scaled agile.”
  • Correct Way: “Write a summary of Practical Scaled Agile certification of CIPSA from ManagementYogi in 100 words or less.”

As you can see, in the first one, we set a clear tone. In the next prompt (or command), we specified CHAMP certification from ManagementYogi, which provided the context. And in the final prompt, we set the boundary to 100 words for the information related to the CIPSA credential. Two hundred words indeed set a constraint.

Using Microsoft Copilot

Among multiple Generative AI (GenAI) models, I found MS Copilot to be the most honest one! 

Others hallucinated and/or many times, provided entirely incorrect information. Microsoft Copilot, a GenAI model, gave the correct information. You can check here.

For MS Copilot, a snippet without the three Cs – clarity, context and constraint – is shown below. You can also write the prompt and test it in various AI models to validate their honesty and integrity. Again, other GenAI models may hallucinate and/or generate completely outlandish information. 

                  

Next, I wrote a prompt with clarity and provided the context. I also set a constraint of 100 words. The response from the AI model is shown below. 

As shown above, the AI model understood. It not only kept it within 100 words, without any extra beautification and addition of its own, but also showed the actual sources. Simple, short, and effective. Other AI models deliberately omitted the source(s) or flip-flopped between showing or not showing the source(s).

Conclusion

Like we apply who, what and why concepts while writing user story on a card, for a prompt too, we can also use them for prompt creation. The table below provides some examples. 

As shown above, we have the examples for both user story and prompts. 

  • For the user story: Who is you as a traveler, what is about choosing the travel date and why is for proper itinerary.  
  • For the prompt: Who is you as a project manager, what is about summarizing the meeting transcript and why is for action items. 

Finally, as noted at the beginning of the article:

  • Agile focuses on delivering value to customers early and frequently.
  • Artificial Intelligence (AI) focuses on extracting value from data.
  • In Agile, the interplay is between team members, whereas in AI, it’s between algorithms and data.

In order to get the right value from an AI model, not only your data, but your prompt also should be good and well-structured. 

Above all, the AI model must have integrity. When you try AI models, also remember to check the integrity of the models and honesty of their responses and ensure right reference sources are provided by the model. 

--

This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away on June 11, 2019. He didn’t just teach me, but taught me how to learn and apply. It’s a tribute to him and his teachings.

--




Wednesday, June 04, 2025

Agile at Scale with CIPSA: The Chief Product Owner (CPO) – What It Is and What It’s Not!


The CIPSA Framework introduces two primary roles for Agile at Scale: Chief Product Owner (CPO) and Principal Scrum Master (PSM) for Scrum or Principal Flow Master (PFM) for Kanban. The CPO role is new and not available in many scaled Agile approaches. However, it is one of the key roles and is crucial for product success. 

In this post, we will learn more on the CPO role as there can be misconceptions and misunderstandings. It’s presented in the form of what it is and what it is not, in order to have more clarity. Do note again, the CPO role applies both to Scrum at Scale and Kanban at Scale.

The following are some of them. To read all articles of this series use this link: What It's and What It's Not series for CIPSA.

Chief Product Owner – What It’s and What It’s Not

1. Not Delegated Vision, but Owned Vision: The Chief Product Owner does not get the product vision from the top executive team. The Chief Product Owner sets the product vision.

The CPO crafts a clear, compelling vision based on customer insights, market trends and business strategy linked to organizational strategy. The CPO leads the product direction and aligns stakeholders around a shared purpose (and goal), instead of relying on top-down directives.

2. Not Management Role, but Visionary Role: The Chief Product Owner is not a portfolio or program manager. The Chief Product Owner is the visionary for the Product.

Unlike a portfolio or program manager who focuses on scope, budgets and/or timelines, the CPO drives the “why” and “what” of the product at scale. The CPO envisions the product’s future and champion its value delivery across the organization.

3. Not Backlog Maintainer, but Backlog Strategist: The Chief Product Owner is not a backlog maintenance person. The Chief Product Owner is the main backlog strategist.

The product backlog, which is only one, is not a list to be managed. The CPO shapes the backlog as a strategic tool to maximize product outcomes and bring value. The CPO makes sure backlog items reflect the product vision, customer needs as well as business priorities. The product backlog is ordered.

4. Not Isolation, but Collaboration: The Chief Product Owner is not a lone-wolf. The Chief Product Owner works with other Team Product Owners, stakeholders and customers.

The Chief Product Owner thrives through collaboration, not isolation. He or she aligns multiple individual team product owners, gathers stakeholders' inputs and integrates customer feedback. Through cross-team communication, the CPO ensures a cohesive and value-driven product evolution.

5. Not Delivery, but Inspection: The Chief Product Owner does not manage the delivery of CIPSA Integrated Increment. The Chief Product Owner inspects whether the CIPSA Integrated Increment meets the CIPSA Goal. 

The CPO doesn’t oversee execution or delivery logistics. Rather, the CPO evaluates outcomes against strategic objectives of the organization. The CPO's focus is ensuring that what is delivered aligns with the overall Product Goal - hence the CPO inspects the CIPSA Integrated Increment. See here.

6. Not CIPSA Goal Ownership, but CIPSA Goal Alignment: The Chief Product Owner is not the owner of the CIPSA Goal. The Chief Product Owner ensures the CIPSA Goal is aligned with the Product Goal.

Unlike the Product Goal, for the CIPSA Goal, the CPO is not the owner. The CPO ensures that it contributes meaningfully to the overarching product goal/objectives. The CPO acts as a bridge here.

7. Not Management Mindset, but Ownership Mindset: The Chief Product Owner is not the manager of the product. The Chief Product Owner is the owner of the Product and has an ownership mindset.

The CPO doesn't manage tasks or people. The CPO takes full accountability for the product’s success. The CPO thinks long-term, acts proactively and leads with a deep sense of responsibility for product outcomes and success.

Summary Table – Chief Product Owner

The following table contrasts common misconceptions with the true nature of the CPO role, highlighting key differences in focus and approach. It's easy to remember and recall. The complete table and explanation are part of the CIPSA certification course.


Closing Remarks

It’s the CPO who first presents the refined Product Backlog to the CIPSA team in the CIPSA Planning meta-event. Only then does the actually planning start, leading to the work items that can be broken down into individual tasks, and finally, execution is done by the CIPSA team to deliver the CIPSA Integrated Increment. See here.

You can also read the unique article - two key roles and goals in CIPSA. See here.

The CPO is indispensable with his/her responsibilities for the success of the product by meeting the Product Goal and hence the Organizational Goals.

The above list of 'what it’s' and 'what it’s not' is a brief one. 

  • Want to know in-depth about the CPO?
  • Want to learn with hands-on, practical software tool?
  • Want to see how the backlog items are prioritized? 
  • Want to break down features in a hands-on manner?

Consider being a CIPSA professional. It’s worth every penny. 


What It's and What It's Not Series:

All Articles in What It's and What It's Not Series - CIPSA

CIPSA Sample Videos and Questions:

[1] CIPSA Sample Video List (Choose a Video)
[2] CIPSA Video Playlist (Complete Playlist)