scrumatscale/official-guide

Repository for the Official Scrum@Scale Guide

official-guide's Issues

Missing description for some of the components in the s@s framework

It’s a bit confusing, that not all of the components are described in the s@s guide or have at least the same titles.

Scaled Events (Daily, Retro clear; Planning, Review not clear)

Guide calls out the need to scale all the events, and clearly marks the Scaled Daily Scrum and Scaled Retro with "Event: ", but then omits calling out a scaled planning and review. If this is intentional (for us to figure out), then I'd recommend clearly saying so. The MetaScrum is not explicitly documented, but seems that would be the scaled planning event. This leaves the scaled review without a recommendation. Seems that should include the whole PO Team with stakeholders plus the SoS Master and representation from each Scrum team, at a minimum.

Define "Linear Scalability"

In the"Why" section of the guide "Linear Scalability" is introduced but not defined. In business structures, the sentence just before gives the opposite of the definition but this is not made clear- the opposite would be adding teams causes delivery to slow down. I'll propose a definition "doubling the number of teams doubles output or better without degradation of quality or happiness." Please make this definition better or feel free to use it as a starter!

Pg. 10 Sentence fragment: "Chang-ing direction of the organization, having to fire 20"

I have already distributed version 1.05 with this issue to my clients CIO and executive directors, who are not looking to fire anyone, as a matter of doing Scrum@Scale. So, this is an unfortunate issue for me in the here and now.

I would like to move forward with an Agile Transformation, and possibly a future S@S Case Study, so the sooner this gets fixed, and the version revved, the better for all of us.

If you have trouble finding the sentence fragment I'm referring to, please read the 2nd to last paragraph on page 10 related to the MetaScrum Event. You will find it reads, "Chang-ing direction of the organization, having to fire 20"

S@S Guide Needs to be Harmonized with ScrumPlop MetaScrum Pattern

The Metascrum is a meeting of the Product Owner team with stakeholders to align and lock down the prioitized backlog (strategy, resources, and implementation). See the ScrumPlop pattern. This is not properly reflected in the Scrum Guide.

Assuring the organic nature of the SoS is maintained + Dev Team's autonomy

Suggestion to be added to the SoS scaling paragraph:

Scaling
Scaling the SoS
Depending upon the size of the organization or implementation, more than one SoS may be needed to deliver a very complex product. In such cases, a Scrum of Scrum of Scrums (SoSoS) can be created out of multiple Scrums of Scrums. The SoSoS is an organic pattern of Scrum Teams which is infinitely scalable. Each SoSoS should have SoSoSMs and scaled versions of each artifact & event. Note that the organic nature of the SoS pattern needs to be maintained when scaling to more SoSs, therefore attention to not removing a Development Team's autonomy is crucial while scaling the SoS.

Scrum@Scale Trainers at Scrum Alliance comments 16 Jul 2018 Denver

Participants will provide dat
AHA Page 8 EAT is accountable for the quality of talent in the organization - Julie
AHA EAT responsible for organizational agility - Dan
AHA What is the ultimate goal - drawing in workshop was helpful
AHA The MetaScrum is the format for stakeholder input and preferences
CHANGE Scaled Daily Scrum should be SoS Daily Meeting (scales up properly) - Dan
CHANGE Specific language changes to make it tighter, shorter sentences - Dan will provide detail
CHANGE Page 7 graphics should be SoSM (maybe SoSSM), maybe two graphs for people and events - Julie
CHANGE Diagram components with inputs and outputs - Simon
CHANGE Big picture - this plugs into this overview
CHANGE Outcome based metrics - customer satisfaction, financial outcomes, employee engagement

One-page guide to scaled teams

Scrum@Scale One-Pager.pdf
I thought a one-page guide to scaled teams would be helpful. I'm attaching a very rough first draft here, in case anyone else thinks this would be helpful. I just completed Scrum@Scale training, and Kim from Scrum Inc. suggested posting suggestions here.

Team Product Owner

It seems there is opportunity to revisit "team PO". It's the source of concern in the CST community and causing immediate dismissal of S@S. It lends itself to the behavior of "take a business analyst and call them team PO". The Scrum Guide seems clear about the level of authority that is needed for a PO. Having a "team level PO" (which 'team PO' suggests whether we like it or not), gets us back into Scrummerfall having a BA acting as go between who is not really empowered. Seems like a simple change to course correct to PO in every sense of the word and focus on CPO as more strategic with PO more tactical but still a PO in the sense of what's conveyed in the Scrum Guide. Would also bring a lot of goodwill about in the very community that this was introduced to in April.

A More Clear Way to Show Fractal Nature of Scrum Teams

The fractal nature of scrum team naming can be simplified. Here is the current nomenclature for 4 levels of teams (e.g., like in the SAAB case study).

• Level 1: Scrum Team (no abbreviation)
• Level 2: Scrum of Scrums (SoS)
• Level 3: Scrum of Scrum of Scrums (SoSoS)
• Level 4: Scrum of Scrum of Scrums of Scrums (SoSoSoS) [Yikes!]

An easier to scale and equally (more?) fractal team nomenclature is below. The numbers would be superscripts. An 'L' could also be inserted before each superscript number.

• Level 1: Scrum Team (1)
• Level 2: Scrum Team (2)
• Level 3: Scrum Team (3)
• Level 4: Scrum Team (4)
• Level n: Scrum Team (n)

Scrum Master cycle owns "THE HOW"?

After a good RSM or RPO class, the students are clear that the PO owns the "What" and the Developers owns the "How".
We have slides with the titles "The Product Owner Owns the What" and "The Developers Owns the HOW".

In the S@S, when we explain the PO cycle and talks about how they own "THE WHAT", as in the diagram. It goes well.

But when we explain the SM Cycle and talks about the "THE HOW" part in the diagram, it can create confusion.

While the intent is clear, it is better to clarify that the SM Cycle owns "THE TRANSFORMATION" or "Continuous Improvement". Or may be remove the "THE HOW" from the diagram?

Refer the diagram: https://www.scrumatscale.com/scrum-at-scale-guide-online/#the-components-of-scrumatscale

Defining S@S

On page 2, Scrum@Scale is referenced without first defining what S@S is. Suggest adding a succinct definition prior to referencing the term.

s@s: Is it a Meta-framework or the new SAFe?

I'm a big fan of keeping S@S simple. Since the new vocabulary for some of the events (e.g. Scaled daily scrum) or roles (chief product owner), etc have been introduced I have the feeling s@s gets unnecessairly complicated and will confuse the attendees. E.g. for the backlog items we also don't call them epics, features, user stories, etc. We call them backlog items and show an example how companies create a hierarchy and agree to common label. Making a long story short: I'd like to start a discussion about if it's not better to keep s@s a meta framework and add examples how events, roles, artifacts, etc have been labeled by companies while our classes or to the appendix of the guide.

cheers Mirko

Update to the visual representation of SoS

S@S guide has some good organizational designs. As I have shared these in the classes, I realized it needs a bit of explanation for people who are not familiar to understand what we are communicating.
So, I did a few experiments and found that students could better connect with slightly different visual representations. Since diagrams are difficult to include here, I am have created the story in a mural page:
https://app.mural.co/invitation/mural/fc3324/1641619983978?sender=shijopaul1061&key=18d50ba3-1d83-476f-a694-6b3c6b079366

Please review and see how we can take this forward.

SoS terminology confusion

Under the "Coordinating the "How" - The Scrum of Scrums" section, the Scrum of Scrums is described as "a set of teams that need to coordinate" and as a "team of teams".
A couple paragraphs later it says "A SoS functions as a Release Team... [and should] have its own roles, artifacts, and events."
Under "Scaling the SoS" it says "Scaling the SoS reduces the number of communication pathways within the organization."

Based on these different characterizations, it is unclear whether SoS refers to the network of coordinated teams, the team of Scrum Masters or representatives from those coordinated teams, or the event now termed the Scaled Daily Scrum whereby communication pathways are reduced while communication saturation is maintained.

It seems to me that the best way of resolving the confusion would be for SoS to refer to the team of SMs, while the "set of teams that need to coordinate" could simply be called "a Network of teams."

S@S Training Comments Cambridge 23-27 Jul 2018

CHANGE Eugene - SM cycle page 6 - Define the SoSoS Scrum Master
CHANGE - Alex - Scaled Daily Scrum, Scaled Scrum Master, Scaled Backlog Refinement
AHA - scale free architecture, everyone in Scrum
CHANGE - Kiran - add content about systems thinking and organizational design (Mid-Continent)
AHA - changes to Guide 1.01 solved some of my suggested changes
CHANGE - Example 7:30-8:45 Scale Daily Meetings for one company (like SAAB)
AHA -
CHANGE - SoS creates an increment
CHANGE - start of document could describe how we work through the diagram in a structured way
CHANGE - cascading acronyms are confusing
CHANGE - inconsistent with Scrum Guide (take stories out of S@S guide)
CHANGE - Scrum Guide DoD is team (who in Scrum@Scale Guide?)
CHANGE - need glossary
CHANGE - scale free confusing (don't need rules?) What is different between scale free and S@S

Clarity on SoS as team of teams vs an event (as used in past)

The term SoS (Scrum of Scrum) used in past to denote an event. In the context of S@S, we refer SoS as a team of teams. This differentiation needs to be highlighted in the guide in the introductory paragraph of SoS.

Clarify the Sprint Review in Scrum@Scale

This may be related to #57 but that issue doesn't call out the Sprint Review. It does call out the backlog refinement and retrospective.

Based on the wording in the Scrum@Scale Guide, it seems like the core Scrum events simply live at the Scrum Team level. However, having worked in organizations at scale, with multiple teams supporting a single product, I have yet to see this be a value adding event when the Sprint Review is scoped to a single team. I've had success with the Sprint Review being a cross-team event that includes all of the Scrum Teams that are supporting a single product. This makes sense since the increment being delivered and reviewed by stakeholders is a single product supported by a single Product Backlog. I'd also note that the other scaled frameworks that specify events (I'm familiar with LeSS, Nexus, and SAFe) have their form of the Sprint Review at a cross-team level.

I'd be curious to see if the Scrum@Scale Guide follows along or if it introduces a new pattern for scaling the Sprint Review event. If the Sprint Review is held at a team level without a cross-team event, I'm curious as to why teams using Scrum@Scale are not having product architecture issues if teams aren't being exposed to each others work via the Sprint Review. If it's held at multiple levels, I'm curious as to how the investment in time from the teams for multiple review events is justified and managed by the organization.

Regardless, I'd like to see some discussion of the Sprint Review event in the Scrum@Scale Guide, minimally with advice on how to make it effective for a scaled environment.

Scrum@Scale Guide in Thai

[
คู่มือ Scrum@Scale .pdf
คู่มือ [email protected]

](url)

Problem with Diagram 2

testing 123

Glossary needed

S@S introduces new terminology and in some instances redefines old terminology. A good example of this is the term of art 'Scrum of Scrums," which most readers associate with an Event (the SMs from each team periodically meeting) but is now the name of a Role (a certain Team) in the S@S Guide. Further, the meeting formally called "Scrum of Scrums" that is in common usage today, is now referred to formally to in the S@S Guide as the Scaled Daily Scrum.

In addition, others here have pointed to the clear need to define essential terms such as [scale free] , [linear scalability] , etc.

In light of the foregoing I am raising the issue of generating a concise Glossary or "Terms of Art" for S@S. I believe we need such a list. Shared word definitions are agreements and as such, are essential.

Clarify S@S does not optimize strategy, optimizes execution of strategy

Our clients say "should I build one factory or two? in which countries?" Scrum@Scale does not answer that, that is their strategy. Scrum@Scale is the engine for execution of that strategy, and that should be clear to our executive clients when they read the guide! What do you all think?

Frequency of the Scaled Daily Scrum

It is clear in the S@S guide that the "Scaled Daily Scrum event mirrors the Daily Scrum" and that "Is time-boxed to 15 minutes or less".

But, it does not explicitly say that the event happens daily. While it is understood, it is better to clarify that explicitly like in Scrum guide:
"to reduce complexity, it is held at the same time and place every working day of the Sprint."

Garbled text in p3 of Nov 2019 PDF

In the note in page 3 (guide-us-english.pdf), there are other characters instead of the expected open and close quotation marks:

These âĂIJservicesâĂİ may

Indirect references to 'EMS as a Team' needs update

Most of the places, it is very clear that EMS is an event.

But, under the "Some Notes on Organizational Design" section, the following note can create some confusion that the EMS is a Team, just like EAT.

"A final note on the representation of the Executive Action Team and the Executive MetaScrum: In this diagram, they are shown as overlapping since some members sit on both of the teams. In very small organizations or implementations, the Executive Action Team and the Executive MetaScrum may consist entirely of the same team members." << highlighted the part which creates confusion that EMS is also a Team.

I would recommend we change this to something like below:
"A final note on the representation of the Executive Action Team and the Executive MetaScrum: In this diagram, they are shown as overlapping since some members sit on both EAT and EMS. In very small organizations or implementations, the Executive Action Team and the Executive MetaScrum event may consist entirely of the same members."

Facilitate the MetaScrum event (see below)

Documentation is confusing where lists one of the Chief Product Owner's responsibilities as "Facilitate the Meta Scrum event (see below)". Below is documentation describing the Executive Meta Scrum event, not the Meta Scrum. Definition of the Meta Scrum is largely assumed as following the "MetaScrum pattern". Diagrams all assume at least three levels, with MS and EMS (as well as SoS and EAT). If SoS and EAT warrant separate discussion, I believe MS and EMS also warrant separate discussion.

Clarity on Coordinating the "How" - The Scrum of Scrums

AS a S@S implementer/ trainer/ coach I would like more clarity on the Scrum of Scrums team goals so that I can help leadership self organized on how to remove impediments for the team and get work that requires team coordination.

Acceptance Criteria: (Please feel free to Comment/ Edit )

1. Clarity that the backlog for the team includes impediments and and items for cross team coordination.
2. Clarity on Events: There are more events than just the SDS and SOS Retrospective - there needs to be backlog refinement for both impediments.
3. Clarity that at least one item out of the SOS retrospective should be include in the SoSM team backlog each sprint.

Note: there is a lot of specificity on the SDS but not much on Retro or Refinement conversations.

Consider Renaming Executive MetaScrum to Executive Product Leadership Team (EPLT)

I'd propose the term 'executive metascrum' doesn't quickly convey the focus of what the team does. Consider using one of the following alternative names:

• Executive Product Leadership Team (EPLT)
• Executive Product Owner Team (EPOT)

In my view, both alternatives are more intuitive and more parallel with the corollary Executive Action Team.

Clarify the "Why" from the Executive perspective

In the "Why Scrum@Scale" section it is explained the why of the framework, but not the why from an executive perspective.
As an Executive level I want to understand the benefits of implementing Scrum@Scale in my organization.

Consider adding a footnote to clarify terms: [Scrum of Scrums] & [Scaled Daily Scrum]

The term "Scrum of Scrums" is in common usage today and commonly refers to a periodic meeting of team representatives, typically the SMs. This term now has a new meaning (it now refers to a Team, a type of Role and not an Event) and further, the Event has a new name: Scaled Daily Scrum.

In light of the foregoing, I propose that a footnote be added in the text, in addition to any Glossary entry that may appear in the Guide.

Rationale: Readers are parsing the text and trying to build understanding by reading sequentially, without skipping around. Adding a footnote that disambiguates the term [Scrum of Scrums] when introduced is therefore essential, at least until the new terminology (as expressed in the Guide) catches on.

Typo in English guide

Typo in the SoS Events:

"The SoSM should faciliate a Backlog Refinement"

facilitate not faciliate

Scrum of Scrums Scrum Master acronym

Hi,

in the Scrum of Scrums chapter, in the "Roles" part, we introduce the "Scrum of Scrums Scrum Master (SoSM)"
This role name has been updated in the 1.01 version, before it was "Scrum of Scrums Master".
The acronym, between parenthesis, is still the old one.
I suspect now it should be "SoS-SM" to reflect the recent changes of the text.

Greetings

Please remove "Roadmap"

The world Roadmap is only used once in the guide, and it sounds IT.

Change "company" to "organization"

In the EMS section is the notion that "the EMS owns
the organizational vision and sets the strategic priorities for the whole
company, aligning all the teams around common goals." (453)

This is the only mention of the word "company". Should this be changed to "organization"?

"Daily Scaled Scrum" problematic semantically

See attached picture for a proposed alternative to an existing slide in "Super-Sized Scrum" module.

When "Daily" precedes Scrum, SoS, SoSoS, etc. we are referring to a meeting
When "Team" follows Scrum, SoS, SoSoS, etc. we are referring to a team

The attached slide shows a situation where I would have had to say "Daily Scaled Scrum" (I guess) for the Daily SoS meeting, and DSSoS? for the Daily SoSoS meeting, which would have been super confusing if I taught to it.

Define "Scale Free Architecture"

The "Why" section introduces "Scale Free Architecture" and it is repeated several times, but not defined. When researching "Scale Free Architecture" we find examples in mathematics, computer networking, biology, etc., but it is not immediately clear how this pertains or not to a business structure of people and services. The answer is likely that scrum teams have a varying number of connections to other scrum teams, each connection having a guaranteed known stable interface of inputs (backlog) and outputs (potentially shippable increments) with transparency through standard work (events). However, this definition or a better one is not given anywhere online as of now, and not within the guide.

Typo - Change 'Teans' to 'Teams'

Typo in the text on the S@S guide, HTML version. Change 'teans' to 'teams' in the passage below. Published at https://www.scrumatscale.com/scrum-at-scale-guide-read-online/

Dealing with Impediments in a SoS
The SoSM should facilitate the refinement of an impediment backlog wherein impediments are identified as “ready” and prioritized to be removed. The teans then determine how best to...

Problem with Meta Scrum Diagram

test issue

SoS retrospective should include improvement items

SoS retrospective should include the improvement areas that the SoS team wishes to implement. Given SoS is a team of teams, they should also have improvement action plan of their own.

Defining Components

Suggest defining components on Page 4 or indicating that the small circles in the S@S Framework graphic are the components (the word component does not appear in the current graphic)

Update Portuguese/Brazil translation

Hi!
I'm very happy with the opportunity to contribute with the Portuguese version, translating the updates of Scrum guide and improving the currently Portuguese version.
For example, there are some typing errors at the Portuguese BR version. But the file is in pdf and I can't edit it. How can I go on? I see some options:
-If you have a ".tex" document, please share it and I can edit it
-If you don't have a ".tex" document, I can create one ".tex" version with full content, but I saw that I'm not allowed to upload files
-I can comment as a new issue for all the typing errors and updates, but doesn't seems to be the best approach, because someone else would need to update
-I can "create a new file" at the default repository, but it seems that the ".tex" is more recommend at "readme"
Regards,
Yolanda

Image cut off in p 18 of Nov 2019 PDF

• The images appear above the line "Sample diagrams:", and
• The image gets cut off or is outside the page width/area

Reconcile S@S Guide Scrum Master Role With Scrum Guide

Someone just highlighted for me the following text in the Scrum (not S@S) guide:

The Scrum Master serves the organization in several ways, including:

• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
  ...

These two bullets seem to be somewhat at odds with the EAT (or Agile Practice in larger implementations). Yes, you can interpret the bullets in a way to make them 'fit', but it would seem cleaner if the bullets as they stand were either modified or removed. I understand Scrum@Scale doesn't have the license to change the Scrum guide. But is this something that can be discussed with Jeff and Ken if it hasn't already?