Scrum at Scale online assessment

Thanks for sharing, Ian.

Interesting assessment. I got 8/10, because I misunderstood one question and didn't know the PMO role in Scaled Scrum.
When can I take the real PSaSM-assessment? ;)

Hi Ian,
How do I take the assessment, when I tried to register, it was asking for registration code,

here is the instructions given in classmarker.com to generate the code
=============
You cannot register to take your Test without your unique Registration code.
Please ask the person giving you the Test for your unique Registration code.

You can copy the link below and email it to your Instructor to show them how to create a registration code for you.
Your unique Registration code can only be created from their account to give you access to your test.

http://www.classmarker.com/online-testing/manual/#addmembersintro
========
can you please help
Thanks
Senthil

I just clicked on the link and took the test fine. I've never been asked to register at any point. Try another browser and see what happens.

Thanks Ian for your quick reply, I tried IE, Chrome & Firefox, it didn't work, here is the error message I got.

"Perhaps this online testing page has moved."

Thanks
Senthil

Hello Senthilkumar,

We're sorry you've been having trouble accessing the Scaling Open assessment. Please navigate to the following link to attempt the free assessment: https://www.scrum.org/Assessments/Open-Assessments/Scaling-Open-Assessm…

If you are still experiencing difficulties, accessing the assessment, users have reported this problem as being resolved by taking the following steps:
- Under the Internet Options on your browser, select Connections / LAN Settings
- Turn off the Proxy server radial button

If your access to the Scrum Open assessment is still being blocked, the cookie policy on your internet browser may need to be set more broadly.

I hope this helps address your issue. Please don't hesitate to reach out to support@scrum.org with further questions or concerns.

Hi Ian,

thanks for the initiative!

@all: what do you think about the following question:

Twelve (12) Scrum Teams are working on a single product. Which one of the following Sprint Planning formats is most likely to be effective?

A)
Product Owners and representatives from the Development Teams meet to define goals, and select Product Backlog items. Development Team representatives then take the assigned Product Backlog items back to their Development Teams for decomposition into a Sprint Backlog.
B)
Product Owners and management may employ a Pre-Sprint Planning Meeting to plan the goals and content of an upcoming Sprint. The Planning Team then shares the work assignments in the Sprint Planning Meeting to the Development Teams who will actually create the product Increment.
C)
All Scrum Teams meet together at the same time in a shared location, and the Product Backlog is visible to all. Scrum Teams figure out what Sprint Goals and Product Backlog they will work on in the upcoming Sprint. They coordinate dependencies, shift team members as needed, and create Sprint Backlogs.

The correct answer is C). I chose A).

Of course, transparency is best achieved with option C) - but is this a viable option? In my mind I have a picture of 80 people in one room discussing wildly and all over the place. This meeting would NEVER come to an end, let alone to a result.

I initially chose A) for the same reason. However Scrum values whole-team collaboration, transparency, and accountability regarding the work a team agrees to do. Sending mere representatives to a Sprint Planning session undoubtedly compromises this principle.

What we learn from C) is that a compromise of this nature may not be sanctioned in order to accommodate scaling demands. This might not be true for scaling approaches that we have seen in the past , but we can infer that it is true for Scrum at Scale. We can also infer that it is up to the teams to self-organize in a way that facilitates this. We might possibly also infer that if they can't self-organize accordingly, then they must challenge the scalability of the product as it may now be effectively a composite one.

Hi Ian,

I can't object your point.It leaves me slightly discontent, though, because I have experienced meetings with 80 people and none of them was efficient. On the other hand, I really love the idea of such a meeting delivering results and by that not compromising the pillar of transparency. Have you ever experienced a meeting like this being efficient or close to?

I've been in release planning sessions that consist of a hundred people or so from all development teams. Each team pins their candidate epics and stories to a wall along with some wireframes for walkthroughs.

Each team then visits the other in rotation, and this seems to be a *reasonably* efficient way of identifying dependencies and other stumbling blocks, and getting a release plan agreed.

This is a big effort and requires all team members to attend for 2 days. It's challenging to try and do this more frequently on a Sprint Planning basis, although the scope is generally reduced and it allows a much better control of uncertainty & risk.

I got 6/10, and i did not pay enough attention to 1 question... still a lot to learn about scrum@scale

Thanks Ian.

One of the questions confuses me.

A multi-national company, which has five major products, is using Scrum for product development. Which statements are the two best alternatives for how many Product Owners exist? (Choose 2.)

A) As many as are needed to communicate expectations and requirements with Development Teams.

B) One specific Product Owner is responsible for all five products. This Product Owner may delegate to others for specific value, capabilities, and functionality within each product.

C) One and only one. The Product Owner may not delegate to others for specific value, capabilities, and functionality.

D) One specific Product Owner is responsible for each product. This Product Owner may delegate to others for specific value, capabilities, and functionality within the product.

Correct answer: B) D)

Could you guys tell me if there is a difference in B and D?

Answer B is clear; Just 1 Product Owner for ALL products.

But answer D says: 1 Product Owner for EACH product. Does this mean that we would have 5 Product Owners or does this mean the same as B, i.e. just 1 Product Owner for ALL products?

> Does this mean that we would have 5 Product Owners

Yes. Five separate products could be represented by between 1 and 5 PO's. The important thing is that no one product is represented by more than 1 PO.

The delegation model that is proposed must be interpreted with caution, lest it be seen to sanction product ownership by proxy. Proxy ownership is controversial and is sometimes considered to be an anti-pattern.

Thank you Ian for the clarification.

Posted By Anke Maerz on 02 Dec 2014 10:28 AM
Hi Ian,

thanks for the initiative!

@all: what do you think about the following question:

Twelve (12) Scrum Teams are working on a single product. Which one of the following Sprint Planning formats is most likely to be effective?

A)
Product Owners and representatives from the Development Teams meet to define goals, and select Product Backlog items. Development Team representatives then take the assigned Product Backlog items back to their Development Teams for decomposition into a Sprint Backlog.
B)
Product Owners and management may employ a Pre-Sprint Planning Meeting to plan the goals and content of an upcoming Sprint. The Planning Team then shares the work assignments in the Sprint Planning Meeting to the Development Teams who will actually create the product Increment.
C)
All Scrum Teams meet together at the same time in a shared location, and the Product Backlog is visible to all. Scrum Teams figure out what Sprint Goals and Product Backlog they will work on in the upcoming Sprint. They coordinate dependencies, shift team members as needed, and create Sprint Backlogs.

The correct answer is C). I chose A).

Of course, transparency is best achieved with option C) - but is this a viable option? In my mind I have a picture of 80 people in one room discussing wildly and all over the place. This meeting would NEVER come to an end, let alone to a result.

Sorry for digging up a 2 year old question but it puzzles me a bit. Initially I also thought Answer A is correct because it's closest to what Nexus recommends BUT if I'm not wrong the question was formulated before Nexus was published which makes it even trickier now.

- The question says 12 teams - which is more than 3 to 9 recommended by Nexus
- The question says all teams work on one product BUT answers A and B say there are Product Owners in plural. Is it enough to discard Answer A and B based on that? On the other hand there are 12 teams which begs for more than one Nexus and PO.
- Answer C also says shift team members as needed - who should be responsible for that and who should make the final call - teams themsevles without even consulting management?

Thanks!

The 12 team issue is a good point, but we are nonetheless constrained to selecting the best of the answers provided.

With 2 years of hindsight I would still say that answer C is the best, but for different reasons. Answer A can be eliminated because it says that PBI's are "assigned" to teams without their agreement. Although Nexus allows for representatives to facilitate team communication during planning, they would not be allowed to assign work to their respective teams. All team members must participate in the agreement of work. Answer B remains incorrect because it would allow management and product owners to disenfranchise team members from this decision. Answer C is best because it demonstrates the principle of self-organizing teams most clearly.

Thanks Ian!

Good catch with the "assigned PBIs" wording. It makes sense to leave Answer C by elimination. I'm still however confused by the "shift team members as needed" part, it's too vague in such form (I wouldn't use that wording when talking to a development team about self-organization).

In Scrum, self-organizing teams are indeed allowed to shift and change membership as needed. This is because they are the ones who are doing the work and who are best positioned to know what it entails.

Generally speaking, in agile and lean practice decision making is devolved and localized. It occurs as close as possible to the time and place of action in order to maximize efficiency and minimize waste.

If a Development Team has to consult with management about these decisions, it implies that the appropriate agile tolerances for the team's remit have not been set. Once suitable tolerances are established a professional team can be trusted to self-organize within those parameters. Management should then become involved only by exception.

In Scrum, self-organizing teams are indeed allowed to shift and change membership as needed. This is because they are the ones who are doing the work and who are best positioned to know what it entails.

Hey Ian, thanks for your response. Would you say teams are allowed to shift and change membership within a single product they work on or across completely different products as well?

Teams have to be prepared to shift and change membership if they are working on the same product. This is because they are jointly and severally responsible for creating an integrated and potentially releasable increment. An impediment that affects one team will impact them all if delivery of the increment is compromised.

However, they also have to be prepared to shift and change the work on their respective Sprint Backlogs. It's generally better to do that, and to replan work so it is handled by the most appropriate team, than to temporarily alter the structure of a team. Such replanning can be addressed in a Nexus Daily Scrum.

If teams are working on separate products they could shift and change membership at their discretion, but neither Scrum nor the Nexus framework has anything to say about this.

Hello Everyone

I managed to score 8/10 in the first pass - without having gone through the Nexus guide and definition of some of the new terms and concepts. I come from a Enterprise solutioning background and have worked on large scale projects involving exposure of various Delivery life cycle practices and competencies - experience helped in interpretations of the terms and scenarios mentioned in the questions.

Ian - on your observations of the wording "assigned PBIs" - not fully aligned with this perspective. When reading the complete sentence -

"Product Owners and representatives from the Development Teams meet to define goals, and select Product Backlog items. Development Team representatives then take the assigned Product Backlog items back to their Development Teams for decomposition into a Sprint Backlog. "

- There is indication that the PBI's were first "selected" by the Representatives. Are we suggesting that in case of Nexus teams - post first selection by Reps - there are additional "Planning" meetings by each Sprint team to further select a sub-set from the Selected PBIs?

Please excuse me for my limited understanding of "Nexus" as I am just about to start going through the same.

The Nexus Guide says that during Nexus Sprint Planning "appropriate representatives from each Scrum Team validate and make adjustments to the ordering of the work as created during Refinement events. All members of the Scrum Teams should participate to minimize communication issues. The Nexus Sprint Goal is formulated during Nexus Sprint Planning. It describes the purpose that will be achieved by the Scrum Teams during the Sprint. Once the overall work for the Nexus is understood, each Scrum Team will perform their own separate Sprint Planning."

Sprint Planning is thus highly collaborative. There is never any assignation of work to others and team representatives do not necessarily make any selection on behalf of their teams at all.

I was reading the same part of the Nexus Guide

"appropriate representatives from each Scrum Team" & " All members of the Scrum Teams" -

The guide seems to be saying both - Appropriate Reps and as well as All Members?

While there is value in "All members" joining the Planning Sessions - at the same time the challenges associated with keeping meeting productive with such large number of participants.

There is no recommendation around TimeBox/Duration of the Nexus Planning Meeting!

I have another question from the same section (Refinement events) of the Text - which I will post as a separate Topic!

This inconsistency has been discussed a couple times, however it's still in the Nexus Guide. Hopefully it's going to be changed in the future.

https://kenschwaber.wordpress.com/2015/01/30/more-on-scaling-scrum/#com…