Scrum is a popular framework for managing complex projects and is widely used in software development. One of Scrum’s fundamental principles is using specific terminology to describe its roles, events, and artifacts. This terminology is designed to promote a shared understanding of the framework and to help teams work together more effectively.
According to the Scrum Guide, it is recommended that teams “adopt and strictly use the Scrum terminology” to maintain a shared understanding and to facilitate communication among team members. However, the Project Management Institute’s (PMI) Guide to the Project Management Body of Knowledge (PMBOK Guide) takes a different approach, stating that “terminology should be tailored to meet the needs of the organization and project stakeholders.”
The main reason for the difference in approach is the nature of the two frameworks. Scrum is a lightweight and highly-iterative framework primarily used in software development. Because of this, Scrum teams must have a common understanding of the framework’s terminology to work together effectively.
On the other hand, PMBOK is a more general framework for project management and is used in various industries. Because of this, it is essential to allow for flexibility in terminology to meet the specific needs of different organizations and projects. In practice, it is crucial to balance the need for a common understanding with flexibility in terminology. Teams that are new to Scrum may benefit from strict adherence to the framework’s terminology, while more experienced teams may find that tailoring the terminology to suit their specific needs better can be beneficial. Ultimately, the decision on whether to adopt Scrum’s terminology as-is or to tailor it will depend on the specific needs of the team and the organization.
An example of when you might want to use strict terminology is when a team is new to Scrum and is just starting to implement the framework. Using the exact Scrum terminology can help the team quickly establish a common understanding of the framework and its key concepts.
For example, if the team is learning about the Scrum roles of Product Owner, Scrum Master, and Development Team, using the exact terms can help to ensure that everyone understands their responsibilities and how they fit into the overall process. This is especially important in the early stages of adopting Scrum when the team is still establishing its workflow and building a shared understanding of the framework.
Another example of when strict terminology would be beneficial is when working with other teams or organizations that also use Scrum. Using the exact Scrum terms can help to facilitate communication and collaboration, as everyone will have a common understanding of the framework and its key concepts. This is particularly useful when working on multi-team projects or integrating with other organizations using Scrum.
In these scenarios, strict adherence to the Scrum terminology would help the team quickly learn the framework and work effectively with other teams.
An example of when you might want to tailor the terminology is when a team has been using Scrum for a while and understands the framework but finds that specific terms are not resonating with stakeholders or customers. In this case, tailoring the terminology can help to improve communication and make the framework more understandable for these external parties.
For example, imagine a team working on a project for a non-technical client who is unfamiliar with Scrum terminology. The team may find that the client is having trouble understanding the role of the Product Owner and the Development Team. In this case, the team might tailor the terminology to suit the clients needs better. Instead of using the Scrum terms, they might use terms that are more familiar to the client, such as “project manager” and “development team.” This will help the client better understand the team’s roles and responsibilities.
Another example is when working in a specific domain or industry, where the specific terminology is already in use by the stakeholders, and that is similar in meaning to the scrum’s, the team can use it instead of Scrum terminology.
For example, a team working on a project in the construction industry might find that using Scrum’s term “Product Backlog” doesn’t resonate with stakeholders and customers in the construction industry who have more familiarity with the term “Work Breakdown Structure” and decide to use that term instead.
In these scenarios, tailoring the terminology can improve communication and make the framework more understandable for stakeholders and customers. It also allows the team to adapt the Scrum framework better to suit the specific needs of their industry or project.
In summary, Scrum recommends strictly using its terminology, whereas PMBOK suggests tailoring it. Scrum is a highly iterative framework primarily used in software development, and the team needs to share a common understanding of the framework’s terminology for practical work. On the other hand, PMBOK is a general framework used in various industries, thus allowing flexibility in terminology to suit the organization’s and stakeholders’ needs.
(*) The numbers in the Case Study are illustrative only and not intended to be accurate.
Copyright 2023
Pete Cooper is a CEO and Program Manager with 20+ years of diverse experience as an Agile Servant leader Program Manager and eight years as a CEO. His career started as a design engineer and grew to the executive level. He has worked in various fields, including Software Development, AI/ML, Product Design, Aviation, App development, RF design, Electronics Design, Mechanical Design, Telehealth, Semiconductors, IoT, and more.
Pete is a thought leader in applying Agile Program Management methodology as a CEO. He has received recognition for overseeing complicated projects in various sectors. He holds an Engineering Degree, MBA, an Airline Pilot’s Licence, and multiple Program Management Certifications, including FAIPM, PSMI I, II, and PMP.
At Skillion, where Pete is the CEO, we pride ourselves on our ability to implement and educate Program Management woven into our customer projects. If you need more than a technical solution managed end to end, don’t hesitate to contact us today to learn more.
