[fa] Farsi | Persian Translation Community

[pedicurus]

Pre-submission Check

• I have checked that this language has not already been proposed or is currently being worked on

Target Language

Farsi

Language Code

fa

Translator Name

Pedram Keshavarzi

Translator Website/Profile (Optional)

https://www.linkedin.com/in/pkeshavarzi/

Translation Experience

Native speaker with translation experience

Scrum Experience

Professional Scrum certification holder

Motivation

When I first started learning Scrum professionally, I turned to the Persian translation of the Scrum Guide — and honestly, I couldn’t understand it. It was clearly translated by multiple people, with inconsistent wording and unfamiliar phrases that didn’t reflect everyday Persian. But when I read the original English version, everything suddenly made sense. That moment sparked a wish in me: “I wish I could’ve done this translation myself — in a way that actually helps beginners like me.”

For example, the word Increment had been translated into a Persian term that’s so outdated and rare that an average person wouldn’t even recognize it. That’s when I realized: we need translations that are simple, clear, and aligned with how Persian is actually spoken today.

Later on, when I advanced my Scrum knowledge from PSM I to PSM III and tried giving constructive feedback to the community that had done the translation, I found they weren’t open to input. That’s when I told myself: “I want to experience this fully — and build a Minimum Viable Translation that my own community can critique and improve — just as Scrum encourages.”

Now, I’m in that position. I host Agile Gap, a Persian-language Agile podcast with over 6,500 active listeners. I’ve officially collaborated with Holisticon AG to translate the Liberating Structures app into Persian. I’ve repeatedly worked through the challenge of translating difficult terms (like Increment) in ways that actually communicate the meaning to my audience — using real feedback from native speakers.

This project is meaningful to me not just personally, but strategically. I plan to share the translation with my community, collect structured feedback (via surveys and discussions), and continuously improve it in an iterative way — just like Scrum itself teaches us. I’ll be in touch regularly to keep the translation aligned with your updates and corrections.

Most of all, I see this as a unique opportunity to collaborate with the very people who shaped the internation Scrum community— Jeff Sutherland, John Coleman, and Ralph Jocham — and to give something truly valuable back to the Persian-speaking Agile community.

Expected Timeline

1-2 weeks

Additional Information

You can use this link to see my podcast website. There are two podcasts, Agile Gap and Boost Agility. Agile Gap is the only podcast about Agile for Persian speakers. Boost Agility is the English podcast that I started recently.

My Podcast Channel Link in Castbox which includes my most listeners (5500 of 6600) and it is transparent for your verfication. Others exist on other podcast hosts like Apple Podcast, Spotify, and Overcast.
I also uploaded two screenshots from the LiSA application. One is related to choose a language and the bottom of Farsi (فارسی), it is written my name (پدرام کشاورزی) as the translator. The other is an example how a structure looks like in Persian in the app.

Agreement

• I understand that this is a volunteer contribution to the community
• I agree to maintain the accuracy and quality of the translation
• I understand that the translation will be published under the same license as the original content
• I am committed to completing the translation in a reasonable timeframe

[MrHinsh]

@pedramthecoder there is already a Farsi proposal at #17

Can you help me understand how this is different?

[pedicurus]

@MrHinsh
It is a ticket for translating Persian or Farsi too. I supposed that you might recieve many proposals until the specific time and choose one of them according to the motivation and committed delivery time, and you hadn't chosen any proposals yet. But it seems you've already chosen. It wasn't transparent for me if you chose or not.

[rjocham]

@pedicurus could you help validate the other Farsi translation. in issue #17. It seems it is fairly progressed.
Thanks for your support.

[pedicurus]

@rjocham
Sure, I did. I also have a few questions about your process for selecting translator candidates.

• Did you select the first person who proposed the Persian translation? It seems so, as I submitted my request less than 24 hours after the expansion was published.
• Could you clarify the purpose of fields like Motivation, Expected Timeline, Scrum Experience, and Translation Experience? I assumed they were meant to help provide transparency and allow for comparison when multiple candidates volunteered.

[MrHinsh]

Did you select the first person who proposed the Persian translation? It seems so, as I submitted my request less than 24 hours after the expansion was published.

These are community and not individual efforts. Once the unique language translation has been created for a language, it becomes the host for collaboration. Folks are expected to self-manage and collaborate on any translation and validation efforts. There is no "selection process".

Could you clarify the purpose of fields like Motivation, Expected Timeline, Scrum Experience, and Translation Experience? I assumed they were meant to help provide transparency and allow for comparison when multiple candidates volunteered.

They are merely to discourage the language from being proposed by someone who has no real interest in the topic. After the initial creation, self-management is expected to follow.

Note: Just as in our working environments, its not required to like everyone we work with to achieve an aim.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been tagged as duplicate and has not had recent activity. It will be closed if no further activity occurs.

[ViralGoodAgile]

Hi folks,

Inspired by another non-Scrum guide website that has the highest quality translations, to the extent that the translations are trusted, the authors of the Scrum Guide Expansion Pack created a Translation Code of Conduct for the Scrum Guide Expansion Pack(SGEP).

The authors of the SGEP were caught a little off guard by the number of translation requests and the level of enthusiasm in a short period.

Translators of the Scrum Guide Expansion Pack and its associated materials do our community an invaluable service and are greatly appreciated. The Code of Conduct for Scrum Guide Expansion Pack Translations outlines expectations and standards to ensure that translation work is of the highest quality and serves the best interests of the communities served by the Scrum Guide Expansion Pack.

Translators must agree to the Translation Code of Conduct before translating, re-translating, or continuing to translate any written materials associated with the Scrum Guide Expansion Pack. All translators in any translation must comply with the Translation Code of Conduct for the Scrum Guide Expansion Pack.

Suggestions to improve the Translation Code of Conduct can be submitted using discussions.

Translation refers to any translated document from the official website(s) publishing the Scrum Guide Expansion Pack, currently the Scrum Guide Expansion Pack website.

A translator is a person who facilitates, creates, amends, or reviews the translation(s) of documents on the official website(s) for accessing the Scrum Guide Expansion Pack.

If any translator is uncomfortable with the Translation Code of Conduct, they must stop their involvement in SGEP translation work and allow other translators to proceed without them. Any perceived breaches of the Translation Code of Conduct may be reported to me privately via email to [email protected], and I will arrange calls to discuss, review the evidence shared with me, and review all sides of such reports. There is no appeals process.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been tagged as duplicate and has not had recent activity. It will be closed if no further activity occurs.

[pedicurus]

Thanks @MrHinsh for your clarification about the process of Translation.

I also thought about your insightful note. I hadn't considered it and it guided me to a new decision. Thanks for that.

P.S. Sorry for answering your comment late. That happened because of the choas situation in Iran.

[pedicurus]

@Alinaderivarandi,
We can continue here.

FYI @sabramooz

[Alinaderivarandi]

Perfect @pedicurus , we stay in touch

[github-actions[bot]]

This issue has been automatically marked as stale because it has been tagged as duplicate and has not had recent activity. It will be closed if no further activity occurs.

[Alinaderivarandi]

@MrHinsh @rjocham ,

For your information: We ( @pedicurus and me) are working on the translation and will share it as soon as it's finished. Project is running and we are on it.

Wish you a relax Sunday.

[Alinaderivarandi]

@MrHinsh, @ViralGoodAgile

If there is feedback regarding the original English Text, where should we share it? the below Text gives me this feeling that either it has an additional word or misses some words in the structure (But keep in Mind English is not my Mother language):

Emergence:
Emergence (71) is when meaningful patterns or behaviors arise from interactions within complex (30-35) systems-patterns you can’t predict just by looking at the parts alone

My Suggestion:

Either we should remove WHEN before meaningful or put it after Meaningful.

[ViralGoodAgile]

Would be a different meaning, so please don't change. Thank you. Kind regards, Orderly Disruption orderlydisruption.com The content of this email is confidential and is only intended for the specified recipient.

…

On Mon, Jun 30, 2025 at 9:09 AM Alinaderivarandi ***@***.***> wrote: *Alinaderivarandi* left a comment (ScrumGuides/ScrumGuide-ExpansionPack#32) <#32 (comment)> @MrHinsh <https://github.com/MrHinsh>, @ViralGoodAgile <https://github.com/ViralGoodAgile> If there is feedback regarding the original English Text, where should we share it? the below Text gives me this feeling that either it has an additional word or misses some words in the structure (But keep in Mind English is not my Mother language): *Emergence: Emergence (71) is when meaningful patterns or behaviors arise from interactions within complex (30-35) systems-patterns you can’t predict just by looking at the parts alone* My Suggestion: Either we should remove *WHEN* before meaningful or put it after *Meaningful*. — Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEYNGVON5NTGOS5YWQTT2T3GDWEFAVCNFSM6AAAAAB7FNJXMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJYGIYDEMRXG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pedicurus]

Dear @MrHinsh
Please remove the label of "duplicate". Because we are going to continue with this issue.

Best
Pedram

[github-actions[bot]]

This issue has been automatically marked as stale because it has been tagged as duplicate and has not had recent activity. It will be closed if no further activity occurs.

[pedicurus]

Dear @MrHinsh, @rjocham, @ViralGoodAgile

@Alinaderivarandi and I discussed if it is better to collaborate here to make the progress transparent for you and the future members of the community, and decided to start it. We had created a group in Telegram and collaborated there. According to the decision, we are going to continue translation and reviewing here. I just want to ensure here is the right place for this purpose, and are you okay with that?

[pedicurus]

@Alinaderivarandi for reviewing:

Multi-Scrum-Team Products
If a Scrum Team becomes too large, it should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same Product. Multiple Scrum Teams on the same Product should share the same Product Goal, Product Backlog, Product Owner, baseline Definition of Outcome Done, and baseline Definition of Output Done.

Be careful with blind assumptions that more value is produced from more Scrum Teams. Scale only when the benefits clearly outweigh the additional overhead. Before you scale, the single Scrum Team setup has to be able to reliably produce an Increment every Sprint. But if you must scale, use an approach that is coherent with this document. Often fewer teams result in more outcomes.

In a multi-Scrum-Team context, Scrum Teams may reduce inter-Scrum-Team dependencies by becoming more cross-functional through collaboration, cross-pollination, transfer of learning, and intentional interactions. The specific skills needed are often broad and will vary with the domain of work. In a multi-Scrum-Team setting, purposeful and intentional interactions and professionalism (including continuous integration) become even more important.

In a one Product Owner and one Scrum Team setup, the Product Owner could be a Product manager, marketing director, technology director, etc. In a multi-Scrum-Team setup for a Product, the ideal is still only one Product Owner, who should be a leader for the Product. To allow the Product Owner to handle multiple Scrum Teams on the same Product, the Product Owner often becomes more strategic and delegates problems to solve and opportunities to the Product Developers, including, for example, aspects of Product design or Product management.

The Product Backlog is a tool for increasing transparency.

Generally, the fewer Product Backlogs per Product, implicit (like a filter of a Product Backlog) or explicit:

The fewer the silos in the Product and the greater the transparency across the entire Product;
The more transparent the overall progress tracking across the entire Product;
The better the big-picture value clarity across the entire Product;
The more likely a Scrum Team would know it’s working on low-value items from a Product perspective;
The more likely one is to observe improvement in the attainment of value; and,
The more strategic the Product Owner becomes by delegating cross-Product work to the Product Developers.
Fewer Product Backlogs per Product are better for adaptiveness (80), but without empowered ownership, a coherent span of control, or direct contact with relevant Stakeholders, gaps will arise. Scrum fosters a climate for happenstance and multi-learning as various people and Scrum Teams collaborate, discoveries and insights can be shared and leveraged. This is unlikely to happen in an environment where each component has a Product Backlog in isolation.

Happenstance in the context of ‘The New New Product Development Game’ (29) means that sometimes useful ideas or solutions come about by chance, not by careful planning. When Scrum Teams work closely together and share information, they might discover new approaches or answers simply because they are open to unexpected events or accidental findings.

Multi-learning means that team members learn in many different ways at the same time. They pick up new skills and knowledge not only in their own area but also in other areas, and they learn as individuals, as a group, and as part of the whole company. This helps the team become more flexible and able to solve a wide range of problems quickly, because everyone is learning from each other and from their experiences as they work together.

Finding the right balance is a dilemma. There are always trade-offs to consider. However, a good heuristic is: The fewer Product Backlogs, implicit or explicit, the better, enabled through multi-learning and the organizational transfer of learning across Scrum Teams, departments, and Products.

Organizational transfer of learning, as described in ‘The New New Product Development Game’ (29), is the process by which knowledge and insights gained in one new Product development area are regularly shared and applied to subsequent areas or other divisions within the organization.

Organizations are often designed for ease of management over ease of outcomes. Ask yourself how many Scrum Teams a problem or opportunity touches to deliver value; generally, the lower that number, the better.

Free teams from command and control. Err on the side of aligned autonomy. Foster purposeful, intentional interactions within and between self-managing Scrum Teams (49). Foster a work climate with minimal but sufficient management processes, scaffolding, and boundaries. Balance and nurture Stakeholder expectations and limits. Build change agency and continual improvement in a direction, not just delivery, into a cadence.

When in doubt, study the New New Product Development Game (29), embrace the good of what’s new in the present, but abandon any notions of an industrial complex (30-35) where only the brave people have the agency to do anything.

محصولات دارای چند تیم اسکرام

اگر یک تیم اسکرام بیش از حد بزرگ شود، باید بازسازمان‌دهی به چند تیم اسکرام منسجم را در نظر بگیرد که همگی بر روی یک محصول متمرکز هستند. تیم‌های اسکرام متعدد روی یک محصول، باید هدف محصول، بکلاگ محصول، مالک محصول، تعریف پایه‌ای نتیجه‌ی مطلوب، و تعریف پایه‌ای انجام کار را با هم به اشتراک بگذارند.

در نظر داشته باشید که فرض نادرست «تعداد بیشتر تیم اسکرام = ارزش بیشتر» می‌تواند گمراه‌کننده باشد. مقیاس را تنها زمانی گسترش دهید که مزایای آن به‌وضوح بر سربار اضافه‌شده غلبه کند. پیش از مقیاس‌پذیری، تنظیمات یک تیم اسکرام باید بتواند به‌طور پایدار در هر اسپرینت یک تکهْ‌محصول تحویل دهد. اما اگر نیاز به مقیاس وجود دارد، روشی را انتخاب کنید که با این مقاله هم‌راستا باشد. در بسیاری از مواقع، تیم‌های کمتر به نتایج بیشتری منجر می‌شوند.

در حوزه‌ی فعالیت چندتیمی، تیم‌های اسکرام می‌توانند با افزایش چندتخصصی بودن از طریق همکاری، تبادل ایده، انتقال یادگیری و تعاملات هدفمند، وابستگی‌های بین تیمی را کاهش دهند. مهارت‌های مورد نیاز معمولاً متنوع هستند و با توجه به حوزه‌ی فعالیت متفاوت‌اند. در چنین محیطی، تعاملات هدفمند و حرفه‌ای‌گری (شامل یکپارچگی مداوم) از اهمیت بیشتری برخوردار می‌شود.

در ساختار یک تیم اسکرام با یک مالک محصول، مالک محصول می‌تواند مدیر محصول، مدیر بازاریابی، مدیر فناوری یا فردی مشابه باشد. در ساختار چندتیمی، همچنان ایده‌آل این است که فقط یک مالک محصول وجود داشته باشد که به‌عنوان رهبر محصول عمل کند. برای مدیریت چند تیم اسکرام روی یک محصول، مالک محصول معمولاً نقش راهبردی‌تری به خود می‌گیرد و برخی مسائل و فرصت‌ها—مانند طراحی محصول یا مدیریت آن—را به توسعه‌دهندگان محصول واگذار می‌کند.

بکلاگ محصول ابزاری برای افزایش شفافیت است.

به‌طور کلی، هرچه تعداد بکلاگ‌های محصول (چه به‌صورت ضمنی و چه صریح) کمتر باشد:

• تعداد کمتری «جزیره» در محصول وجود خواهد داشت و شفافیت در کل محصول افزایش می‌یابد؛
• پیگیری پیشرفت در کل محصول شفاف‌تر خواهد بود؛
• وضوح دیدگاه کلی ارزش بهتر خواهد شد؛
• احتمال بیشتری وجود دارد که یک تیم اسکرام متوجه شود در حال کار روی آیتم‌هایی با ارزش پایین است؛
• احتمال بیشتری وجود دارد که بهبود در دستیابی به ارزش قابل مشاهده شود؛
• و مالک محصول می‌تواند نقش راهبردی‌تری ایفا کند با واگذاری کارهای بین‌محصولی به توسعه‌دهندگان محصول.

بکلاگ‌های کمتر در هر محصول به سازگاری (80) کمک می‌کنند، اما اگر مالکیت توانمند، دامنه‌ی کنترل منسجم، یا ارتباط مستقیم با ذینفعان وجود نداشته باشد، شکاف‌هایی به‌وجود می‌آید. اسکرام فضایی ایجاد می‌کند برای بخت‌یافتگی و یادگیری چندجانبه؛ جایی که افراد مختلف و تیم‌های اسکرام با همکاری، کشف‌ها و بینش‌های خود را به اشتراک می‌گذارند و از آن‌ها بهره می‌برند. این امر در محیطی که هر جزء، بکلاگ محصول جداگانه دارد، بعید است رخ دهد.

در مقاله‌ی The New New Product Development Game (29)، «بخت‌یافتگی» به حالتی اشاره دارد که ایده‌ها یا راه‌حل‌های مفید نه از برنامه‌ریزی دقیق، بلکه به‌صورت اتفاقی و در نتیجه‌ی تعاملات باز پدید می‌آیند. وقتی تیم‌های اسکرام به‌طور نزدیک با هم همکاری کرده و اطلاعات را به اشتراک می‌گذارند، ممکن است تنها به‌خاطر باز بودن نسبت به رویدادهای پیش‌بینی‌نشده، به بینش‌های جدیدی برسند.

یادگیری چندجانبه یعنی اعضای تیم به‌صورت هم‌زمان و به شیوه‌های گوناگون یاد می‌گیرند. آن‌ها نه‌فقط در حوزه‌ی تخصصی خود، بلکه در زمینه‌های دیگر نیز مهارت و دانش کسب می‌کنند—چه به‌صورت فردی، چه به‌عنوان تیم، چه در سطح کل شرکت. این امر تیم را منعطف‌تر می‌سازد و توانایی حل مسائل مختلف را به‌سرعت افزایش می‌دهد، چرا که همه از هم و از تجربیات مشترک در حین کار می‌آموزند.

یافتن توازن درست یک دوگانگی است. همیشه باید موازنه‌ی منافع و هزینه‌ها را در نظر گرفت. اما یک قاعده‌ی مفید این است: هرچه تعداد بکلاگ‌های محصول، چه ضمنی چه صریح، کمتر باشد، بهتر است—به‌ویژه اگر این موضوع از طریق یادگیری چندجانبه و انتقال سازمانی یادگیری در میان تیم‌های اسکرام، واحدها و محصولات پشتیبانی شود.

انتقال سازمانی یادگیری، همان‌طور که در The New New Product Development Game (29) توضیح داده شده، فرایندی است که طی آن، دانش و بینش‌های به‌دست‌آمده در یک حوزه از توسعه‌ی محصول به‌صورت منظم به سایر بخش‌ها یا حوزه‌های دیگر سازمان منتقل و به‌کار گرفته می‌شود.

سازمان‌ها اغلب برای سهولت مدیریت طراحی می‌شوند، نه سهولت در دستیابی به نتایج. از خود بپرسید که برای حل یک مسئله یا بهره‌برداری از یک فرصت، چند تیم اسکرام باید درگیر شوند؛ به‌طور کلی، هرچه این عدد کمتر باشد، بهتر است.

تیم‌ها را از قید و بند کنترل و فرمان آزاد کنید. به‌سمت خودمختاری هم‌راستا متمایل شوید. تعاملات هدفمند و آگاهانه درون و میان تیم‌های خودگردان اسکرام (49) را پرورش دهید. محیط کاری را با کم‌ترین ولی کافی‌ترین فرآیندهای مدیریتی، ساختار پشتیبان و مرزها شکل دهید. انتظارات و محدودیت‌های ذینفعان را متوازن و تغذیه کنید. عاملیت تغییر و بهبود مستمر را در یک مسیر هدف‌مند—نه فقط در تحویل—به ریتم کاری وارد کنید.

در صورت تردید، مقاله‌ی The New New Product Development Game (29) را مطالعه کنید، از خوبی‌های دنیای امروز بهره بگیرید، اما هر تصور صنعتی‌شده‌ای را که تنها افراد شجاع در آن اختیار عمل دارند، کنار بگذارید.

[pedicurus]

@Alinaderivarandi for reviewing:

End Note
Jeff Sutherland’s 1993 Scrum adoption at Easel was inspired by Christopher Langton’s papers (36,37) on Complex Adaptive Systems (CAS) (74-77) theory from Los Alamos Labs, which shows that systems evolve quicker at the edge of chaos.

Scrum is described in the 2020 Scrum Guide (40). Tobias Mayer’s A Simple Guide to Scrum (58) is a shortened, edited version of the official Scrum Guide by Ken Schwaber and Jeff Sutherland. The Scrum Hexis (52) elaborates on the 2020 Scrum Guide from a 2025 perspective, but the 2020 Scrum Guide is still the essential reference for Scrum.

Scrum is like a mirror. If the image in the mirror is not as expected, should the mirror be hidden?

Attain at least one Increment each Sprint as a habit before you adapt Scrum. Every part of Scrum has a purpose; understanding the why for each part is essential. Consider the context. The short-term is about delivery. The long-term is about successful emergent change in a direction and the sustainable delivery of value. Successful Scrum adoption depends on getting the balance right between the short and long terms.

Be careful about copying approaches from other organizations without also fostering their culture. Emergent change in the direction of travel is the change. The change includes (but is not limited to) leadership, workflows, processes, and systems, including HR, Finance, Procurement, and more. Scrum is part of a never-ending expedition of continual improvement and evolution in a direction of travel rather than a destination.

یادداشت پایانی

(لینک دارد)

پیاده‌سازی اسکرام توسط جف ساترلند در سال ۱۹۹۳ در شرکت Easel از مقالات کریستوفر لنگتون (36،37) درباره‌ی نظریه‌ی سیستم‌های تطبیقی پیچیده (Complex Adaptive Systems یا CAS) (74–77) در آزمایشگاه‌های Los Alamos الهام گرفته بود—نظریه‌ای که نشان می‌دهد سیستم‌ها در لبه‌ی آشوب سریع‌تر تکامل می‌یابند.

اسکرام در نسخه‌ی ۲۰۲۰ راهنمای اسکرام (40) توصیف شده است. کتاب A Simple Guide to Scrum نوشته‌ی Tobias Mayer (58)، نسخه‌ای خلاصه‌شده و ویرایش‌شده از راهنمای رسمی اسکرام نوشته‌ی کن شبر و جف ساترلند است. مقاله‌ی Scrum Hexis (52) از منظر سال ۲۰۲۵، راهنمای ۲۰۲۰ اسکرام را بسط می‌دهد، اما راهنمای ۲۰۲۰ همچنان مرجع اصلی اسکرام محسوب می‌شود.

اسکرام مانند آینه‌ای است. اگر تصویری که در آینه دیده می‌شود مطابق انتظار نیست، آیا باید آینه را پنهان کرد؟

پیش از این‌که بخواهید اسکرام را تغییر دهید، ابتدا عادت کنید که در هر اسپرینت دست‌کم یک تکهْ‌محصول بسازید. هر بخش از اسکرام دلیلی دارد؛ درک چرایی هر بخش ضروری است. حوزه‌ی فعالیت را در نظر بگیرید. در کوتاه‌مدت، تمرکز بر تحویل است؛ در بلندمدت، تمرکز بر تغییر پدیداری موفق در یک مسیر و تحویل پایدار ارزش است. پذیرش موفق اسکرام به ایجاد توازن درست میان کوتاه‌مدت و بلندمدت وابسته است.

در کپی‌کردن رویکردهای سازمان‌های دیگر احتیاط کنید، مگر این‌که فرهنگ آن‌ها را نیز پرورش دهید. تغییر پدیداری در مسیر حرکت، خود تغییر است. این تغییر شامل (اما نه محدود به) رهبری، جریان‌های کاری، فرایندها و سیستم‌ها، از جمله منابع انسانی، مالی، تدارکات و غیره می‌شود. اسکرام بخشی از یک سفر بی‌پایان برای بهبود مستمر و تکامل در یک مسیر مشخص است—نه رسیدن به یک مقصد.

[pedicurus]

@Alinaderivarandi for reviewing:

Acknowledgments
Scrum was inspired by Lean (63), the Toyota Production System (59-60), the Harvard Business Review article ‘The New New Product Development Game’ by Hirotaka Takeuchi and Ikujiro Nonaka (29), and Empiricism at Dupont (61).

Scrum was developed in the early 1990s. Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA Conference in 1995 (62). The first version of the Scrum Guide (40) appeared in 2009. Scrum is evolving.

We also thank reviewers who provided feedback to earlier drafts, including but not limited to, Daryn Basson, Alex Benes, Kurt Bittner, Deb Bhattacharya, Magdalena Firlit, Nichervan Fazel, Peter Fischbach, Michael Forni, Tom Gilb, Martin Hinshelwood, Jesse Houwing, Michael Huynh, Matthew Ijogi, Marc Kaufmann, Tom Mellor, Christian Neverdal, Stas Pavlov, Ian Sharp, Alisa Stolze, Mark Summers, and Nader Talai.

قدردانی

اسکرام از تفکر ناب (63)، سیستم تولید تویوتا (59–60)، مقاله‌ی منتشرشده در Harvard Business Review با عنوان «بازی جدید توسعه‌ی محصول» نوشته‌ی هیروتاکا تاکئوچی و ایکوجیرو نوناکا (29)، و تجربه‌گرایی در شرکت دوپونت (61) الهام گرفته است.

اسکرام در اوایل دهه‌ی ۱۹۹۰ توسعه یافت. کن شبر و جف ساترلند اولین‌بار در سال ۱۹۹۵ در کنفرانس OOPSLA (62) اسکرام را به‌صورت مشترک ارائه کردند. اولین نسخه از راهنمای اسکرام (40) در سال ۲۰۰۹ منتشر شد. اسکرام در حال تکامل است.

همچنین از بازبینانی که به نسخه‌های اولیه‌ی این مقاله بازخورد داده‌اند قدردانی می‌کنیم، از جمله (اما نه محدود به): Daryn Basson، Alex Benes، Kurt Bittner، Deb Bhattacharya، Magdalena Firlit، Nichervan Fazel، Peter Fischbach، Michael Forni، Tom Gilb، Martin Hinshelwood، Jesse Houwing، Michael Huynh، Matthew Ijogi، Marc Kaufmann، Tom Mellor، Christian Neverdal، Stas Pavlov، Ian Sharp، Alisa Stolze، Mark Summers و Nader Talai.

(لینک دارد)

[pedicurus]

Dear @MrHinsh

Can you move this issue to Farsi Category?

https://github.com/ScrumGuides/ScrumGuide-ExpansionPack/discussions/categories/farsi-language

[pedicurus]

@Alinaderivarandi I'd prefere to use "تعریف خروجی مطلوب" instead of "Definition of Output Done". It does make more sense. Because we use "تعریف نتیجه‌ی مطلوب" instead of "Definition of Outcome Done".

What is your idea?

P.S. We used to decide to use "تعریف انجام کار" for Definition of Done. But it was replaced by "Definition of Output Done".

[Alinaderivarandi]

@Alinaderivarandi for reviewing:

Multi-Scrum-Team Products If a Scrum Team becomes too large, it should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same Product. Multiple Scrum Teams on the same Product should share the same Product Goal, Product Backlog, Product Owner, baseline Definition of Outcome Done, and baseline Definition of Output Done.

Be careful with blind assumptions that more value is produced from more Scrum Teams. Scale only when the benefits clearly outweigh the additional overhead. Before you scale, the single Scrum Team setup has to be able to reliably produce an Increment every Sprint. But if you must scale, use an approach that is coherent with this document. Often fewer teams result in more outcomes.

In a multi-Scrum-Team context, Scrum Teams may reduce inter-Scrum-Team dependencies by becoming more cross-functional through collaboration, cross-pollination, transfer of learning, and intentional interactions. The specific skills needed are often broad and will vary with the domain of work. In a multi-Scrum-Team setting, purposeful and intentional interactions and professionalism (including continuous integration) become even more important.

In a one Product Owner and one Scrum Team setup, the Product Owner could be a Product manager, marketing director, technology director, etc. In a multi-Scrum-Team setup for a Product, the ideal is still only one Product Owner, who should be a leader for the Product. To allow the Product Owner to handle multiple Scrum Teams on the same Product, the Product Owner often becomes more strategic and delegates problems to solve and opportunities to the Product Developers, including, for example, aspects of Product design or Product management.

The Product Backlog is a tool for increasing transparency.

Generally, the fewer Product Backlogs per Product, implicit (like a filter of a Product Backlog) or explicit:

The fewer the silos in the Product and the greater the transparency across the entire Product; The more transparent the overall progress tracking across the entire Product; The better the big-picture value clarity across the entire Product; The more likely a Scrum Team would know it’s working on low-value items from a Product perspective; The more likely one is to observe improvement in the attainment of value; and, The more strategic the Product Owner becomes by delegating cross-Product work to the Product Developers. Fewer Product Backlogs per Product are better for adaptiveness (80), but without empowered ownership, a coherent span of control, or direct contact with relevant Stakeholders, gaps will arise. Scrum fosters a climate for happenstance and multi-learning as various people and Scrum Teams collaborate, discoveries and insights can be shared and leveraged. This is unlikely to happen in an environment where each component has a Product Backlog in isolation.

Happenstance in the context of ‘The New New Product Development Game’ (29) means that sometimes useful ideas or solutions come about by chance, not by careful planning. When Scrum Teams work closely together and share information, they might discover new approaches or answers simply because they are open to unexpected events or accidental findings.

Multi-learning means that team members learn in many different ways at the same time. They pick up new skills and knowledge not only in their own area but also in other areas, and they learn as individuals, as a group, and as part of the whole company. This helps the team become more flexible and able to solve a wide range of problems quickly, because everyone is learning from each other and from their experiences as they work together.

Finding the right balance is a dilemma. There are always trade-offs to consider. However, a good heuristic is: The fewer Product Backlogs, implicit or explicit, the better, enabled through multi-learning and the organizational transfer of learning across Scrum Teams, departments, and Products.

Organizational transfer of learning, as described in ‘The New New Product Development Game’ (29), is the process by which knowledge and insights gained in one new Product development area are regularly shared and applied to subsequent areas or other divisions within the organization.

Organizations are often designed for ease of management over ease of outcomes. Ask yourself how many Scrum Teams a problem or opportunity touches to deliver value; generally, the lower that number, the better.

Free teams from command and control. Err on the side of aligned autonomy. Foster purposeful, intentional interactions within and between self-managing Scrum Teams (49). Foster a work climate with minimal but sufficient management processes, scaffolding, and boundaries. Balance and nurture Stakeholder expectations and limits. Build change agency and continual improvement in a direction, not just delivery, into a cadence.

When in doubt, study the New New Product Development Game (29), embrace the good of what’s new in the present, but abandon any notions of an industrial complex (30-35) where only the brave people have the agency to do anything.

محصولات دارای چند تیم اسکرام

اگر یک تیم اسکرام بیش از حد بزرگ شود، باید بازسازمان‌دهی به چند تیم اسکرام منسجم را در نظر بگیرد که همگی بر روی یک محصول متمرکز هستند. تیم‌های اسکرام متعدد روی یک محصول، باید هدف محصول، بکلاگ محصول، مالک محصول، تعریف پایه‌ای نتیجه‌ی مطلوب، و تعریف پایه‌ای انجام کار را با هم به اشتراک بگذارند.

در نظر داشته باشید که فرض نادرست «تعداد بیشتر تیم اسکرام = ارزش بیشتر» می‌تواند گمراه‌کننده باشد. مقیاس را تنها زمانی گسترش دهید که مزایای آن به‌وضوح بر سربار اضافه‌شده غلبه کند. پیش از مقیاس‌پذیری، تنظیمات یک تیم اسکرام باید بتواند به‌طور پایدار در هر اسپرینت یک تکهْ‌محصول تحویل دهد. اما اگر نیاز به مقیاس وجود دارد، روشی را انتخاب کنید که با این مقاله هم‌راستا باشد. در بسیاری از مواقع، تیم‌های کمتر به نتایج بیشتری منجر می‌شوند.

در حوزه‌ی فعالیت چندتیمی، تیم‌های اسکرام می‌توانند با افزایش چندتخصصی بودن از طریق همکاری، تبادل ایده، انتقال یادگیری و تعاملات هدفمند، وابستگی‌های بین تیمی را کاهش دهند. مهارت‌های مورد نیاز معمولاً متنوع هستند و با توجه به حوزه‌ی فعالیت متفاوت‌اند. در چنین محیطی، تعاملات هدفمند و حرفه‌ای‌گری (شامل یکپارچگی مداوم) از اهمیت بیشتری برخوردار می‌شود.

در ساختار یک تیم اسکرام با یک مالک محصول، مالک محصول می‌تواند مدیر محصول، مدیر بازاریابی، مدیر فناوری یا فردی مشابه باشد. در ساختار چندتیمی، همچنان ایده‌آل این است که فقط یک مالک محصول وجود داشته باشد که به‌عنوان رهبر محصول عمل کند. برای مدیریت چند تیم اسکرام روی یک محصول، مالک محصول معمولاً نقش راهبردی‌تری به خود می‌گیرد و برخی مسائل و فرصت‌ها—مانند طراحی محصول یا مدیریت آن—را به توسعه‌دهندگان محصول واگذار می‌کند.

بکلاگ محصول ابزاری برای افزایش شفافیت است.

به‌طور کلی، هرچه تعداد بکلاگ‌های محصول (چه به‌صورت ضمنی و چه صریح) کمتر باشد:

• تعداد کمتری «جزیره» در محصول وجود خواهد داشت و شفافیت در کل محصول افزایش می‌یابد؛
• پیگیری پیشرفت در کل محصول شفاف‌تر خواهد بود؛
• وضوح دیدگاه کلی ارزش بهتر خواهد شد؛
• احتمال بیشتری وجود دارد که یک تیم اسکرام متوجه شود در حال کار روی آیتم‌هایی با ارزش پایین است؛
• احتمال بیشتری وجود دارد که بهبود در دستیابی به ارزش قابل مشاهده شود؛
• و مالک محصول می‌تواند نقش راهبردی‌تری ایفا کند با واگذاری کارهای بین‌محصولی به توسعه‌دهندگان محصول.

بکلاگ‌های کمتر در هر محصول به سازگاری (80) کمک می‌کنند، اما اگر مالکیت توانمند، دامنه‌ی کنترل منسجم، یا ارتباط مستقیم با ذینفعان وجود نداشته باشد، شکاف‌هایی به‌وجود می‌آید. اسکرام فضایی ایجاد می‌کند برای بخت‌یافتگی و یادگیری چندجانبه؛ جایی که افراد مختلف و تیم‌های اسکرام با همکاری، کشف‌ها و بینش‌های خود را به اشتراک می‌گذارند و از آن‌ها بهره می‌برند. این امر در محیطی که هر جزء، بکلاگ محصول جداگانه دارد، بعید است رخ دهد.

در مقاله‌ی The New New Product Development Game (29)، «بخت‌یافتگی» به حالتی اشاره دارد که ایده‌ها یا راه‌حل‌های مفید نه از برنامه‌ریزی دقیق، بلکه به‌صورت اتفاقی و در نتیجه‌ی تعاملات باز پدید می‌آیند. وقتی تیم‌های اسکرام به‌طور نزدیک با هم همکاری کرده و اطلاعات را به اشتراک می‌گذارند، ممکن است تنها به‌خاطر باز بودن نسبت به رویدادهای پیش‌بینی‌نشده، به بینش‌های جدیدی برسند.

یادگیری چندجانبه یعنی اعضای تیم به‌صورت هم‌زمان و به شیوه‌های گوناگون یاد می‌گیرند. آن‌ها نه‌فقط در حوزه‌ی تخصصی خود، بلکه در زمینه‌های دیگر نیز مهارت و دانش کسب می‌کنند—چه به‌صورت فردی، چه به‌عنوان تیم، چه در سطح کل شرکت. این امر تیم را منعطف‌تر می‌سازد و توانایی حل مسائل مختلف را به‌سرعت افزایش می‌دهد، چرا که همه از هم و از تجربیات مشترک در حین کار می‌آموزند.

یافتن توازن درست یک دوگانگی است. همیشه باید موازنه‌ی منافع و هزینه‌ها را در نظر گرفت. اما یک قاعده‌ی مفید این است: هرچه تعداد بکلاگ‌های محصول، چه ضمنی چه صریح، کمتر باشد، بهتر است—به‌ویژه اگر این موضوع از طریق یادگیری چندجانبه و انتقال سازمانی یادگیری در میان تیم‌های اسکرام، واحدها و محصولات پشتیبانی شود.

انتقال سازمانی یادگیری، همان‌طور که در The New New Product Development Game (29) توضیح داده شده، فرایندی است که طی آن، دانش و بینش‌های به‌دست‌آمده در یک حوزه از توسعه‌ی محصول به‌صورت منظم به سایر بخش‌ها یا حوزه‌های دیگر سازمان منتقل و به‌کار گرفته می‌شود.

سازمان‌ها اغلب برای سهولت مدیریت طراحی می‌شوند، نه سهولت در دستیابی به نتایج. از خود بپرسید که برای حل یک مسئله یا بهره‌برداری از یک فرصت، چند تیم اسکرام باید درگیر شوند؛ به‌طور کلی، هرچه این عدد کمتر باشد، بهتر است.

تیم‌ها را از قید و بند کنترل و فرمان آزاد کنید. به‌سمت خودمختاری هم‌راستا متمایل شوید. تعاملات هدفمند و آگاهانه درون و میان تیم‌های خودگردان اسکرام (49) را پرورش دهید. محیط کاری را با کم‌ترین ولی کافی‌ترین فرآیندهای مدیریتی، ساختار پشتیبان و مرزها شکل دهید. انتظارات و محدودیت‌های ذینفعان را متوازن و تغذیه کنید. عاملیت تغییر و بهبود مستمر را در یک مسیر هدف‌مند—نه فقط در تحویل—به ریتم کاری وارد کنید.

در صورت تردید، مقاله‌ی The New New Product Development Game (29) را مطالعه کنید، از خوبی‌های دنیای امروز بهره بگیرید، اما هر تصور صنعتی‌شده‌ای را که تنها افراد شجاع در آن اختیار عمل دارند، کنار بگذارید.

The Translation looks good; however, we need to discuss the meaning of 'Silo' in Farsi. This is a challenging Phrase, which needs to be added to our Agreement List. The rest are understandable and clear without changing the context and meaning of the main expansion Guide.

[Alinaderivarandi]

@Alinaderivarandi for reviewing:

End Note Jeff Sutherland’s 1993 Scrum adoption at Easel was inspired by Christopher Langton’s papers (36,37) on Complex Adaptive Systems (CAS) (74-77) theory from Los Alamos Labs, which shows that systems evolve quicker at the edge of chaos.

Scrum is described in the 2020 Scrum Guide (40). Tobias Mayer’s A Simple Guide to Scrum (58) is a shortened, edited version of the official Scrum Guide by Ken Schwaber and Jeff Sutherland. The Scrum Hexis (52) elaborates on the 2020 Scrum Guide from a 2025 perspective, but the 2020 Scrum Guide is still the essential reference for Scrum.

Scrum is like a mirror. If the image in the mirror is not as expected, should the mirror be hidden?

Attain at least one Increment each Sprint as a habit before you adapt Scrum. Every part of Scrum has a purpose; understanding the why for each part is essential. Consider the context. The short-term is about delivery. The long-term is about successful emergent change in a direction and the sustainable delivery of value. Successful Scrum adoption depends on getting the balance right between the short and long terms.

Be careful about copying approaches from other organizations without also fostering their culture. Emergent change in the direction of travel is the change. The change includes (but is not limited to) leadership, workflows, processes, and systems, including HR, Finance, Procurement, and more. Scrum is part of a never-ending expedition of continual improvement and evolution in a direction of travel rather than a destination.

یادداشت پایانی

(لینک دارد)

پیاده‌سازی اسکرام توسط جف ساترلند در سال ۱۹۹۳ در شرکت Easel از مقالات کریستوفر لنگتون (36،37) درباره‌ی نظریه‌ی سیستم‌های تطبیقی پیچیده (Complex Adaptive Systems یا CAS) (74–77) در آزمایشگاه‌های Los Alamos الهام گرفته بود—نظریه‌ای که نشان می‌دهد سیستم‌ها در لبه‌ی آشوب سریع‌تر تکامل می‌یابند.

اسکرام در نسخه‌ی ۲۰۲۰ راهنمای اسکرام (40) توصیف شده است. کتاب A Simple Guide to Scrum نوشته‌ی Tobias Mayer (58)، نسخه‌ای خلاصه‌شده و ویرایش‌شده از راهنمای رسمی اسکرام نوشته‌ی کن شبر و جف ساترلند است. مقاله‌ی Scrum Hexis (52) از منظر سال ۲۰۲۵، راهنمای ۲۰۲۰ اسکرام را بسط می‌دهد، اما راهنمای ۲۰۲۰ همچنان مرجع اصلی اسکرام محسوب می‌شود.

اسکرام مانند آینه‌ای است. اگر تصویری که در آینه دیده می‌شود مطابق انتظار نیست، آیا باید آینه را پنهان کرد؟

پیش از این‌که بخواهید اسکرام را تغییر دهید، ابتدا عادت کنید که در هر اسپرینت دست‌کم یک تکهْ‌محصول بسازید. هر بخش از اسکرام دلیلی دارد؛ درک چرایی هر بخش ضروری است. حوزه‌ی فعالیت را در نظر بگیرید. در کوتاه‌مدت، تمرکز بر تحویل است؛ در بلندمدت، تمرکز بر تغییر پدیداری موفق در یک مسیر و تحویل پایدار ارزش است. پذیرش موفق اسکرام به ایجاد توازن درست میان کوتاه‌مدت و بلندمدت وابسته است.

در کپی‌کردن رویکردهای سازمان‌های دیگر احتیاط کنید، مگر این‌که فرهنگ آن‌ها را نیز پرورش دهید. تغییر پدیداری در مسیر حرکت، خود تغییر است. این تغییر شامل (اما نه محدود به) رهبری، جریان‌های کاری، فرایندها و سیستم‌ها، از جمله منابع انسانی، مالی، تدارکات و غیره می‌شود. اسکرام بخشی از یک سفر بی‌پایان برای بهبود مستمر و تکامل در یک مسیر مشخص است—نه رسیدن به یک مقصد.

@pedicurus Scrum Hexis is not an article; what is translated here is in the Scrum Hexis Article. We need only write Scrum Hexis.

[Alinaderivarandi]

@Alinaderivarandi I'd prefere to use "تعریف خروجی مطلوب" instead of "Definition of Output Done". It does make more sense. Because we use "تعریف نتیجه‌ی مطلوب" instead of "Definition of Outcome Done".

What is your idea?

P.S. We used to decide to use "تعریف انجام کار" for Definition of Done. But it was replaced by "Definition of Output Done".

@pedicurus yes, ''تعریف نتیجه‌ی مطلوب" make much more sense. Im with you

[rjocham]

Hey Farsi translators, thanks for your hard work. Your translation went live, if there any issues please let us know.
If you are ok, feel free to go wild on social media.