A single instance of Scrum has one Scrum Team that works from one Product Backlog. The team sprints against the selected Product Backlog items and creates an increment of potentially shippable, or usable, functionality by the end of the Sprint
If you want to test your knowledge of scaling Scrum, I set up a little test for you
From the outside, Scaling Scrum is exactly the same. One Product Backlog provides input to a Sprint. At the end of the Sprint, an increment of potentially shippable functionality has been developed and is ready for use. However, on one or more Sprints the Product Owner has chosen to employ more than one Scrum Team. The number of Scrum Teams can be constant and their composition can remain the same, or not.
Reasons for Scaling Scrum include:
- Desire to complete functionality more rapidly by applying more Scrum Teams to the Product Backlog.
- Need to apply more people to the Product Backlog for one or more Sprints than can be readily accommodated in one Scrum Team. A singularity of diverse skills applied at one time may generate this need, such as developing a user interface framework, secure architecture, and piece of functionality within one Sprint.
All of the basic values, principles, artifacts, roles, and meetings of Scrum apply, whether Scrum is singular or scaled. These remain inviolate for the purposes of controlling risk, generating creativity and productivity, and creating transparency.
As more Scrum Teams work together on a Product Backlog, the number of interactions, complexities, and non-linear events increase. The relationship between productivity/creativity and the number of Scrum Teams is not linear. Product Owners employing multiple Scrum Teams need to carefully weigh the benefits and costs.
Scaling Scrum is a program from Scrum.org to manage and operate multi-Scrum Team initiatives. Techniques for organizing and selecting Product Backlog items, resolving dependencies and integrating work, and creating “done” increments are evaluated. Since every development situation is different (domain, people, technology), every set of techniques is unique and often has to change with time.
Scaling Scrum is a hands-on, sleeves rolled up workshop where people figure out one instance and nuances of other instances of scaling Scrum that might work for their projects, releases, initiatives, or organizations. This is not a management overview. The people who will setup, run, coach, and optimize multi-Scrum team initiatives are the audience.
We want to help you determine if this workshop is for you. To that end, we have developed a ten-question test that you can use to assess your knowledge (or desired knowledge) of techniques for scaling Scrum. You can take it at no charge.
If the assessment addresses the issues you want to tackle, sign up for the workshop . We look forward to sharing our experience scaling Scrum with you.
The Scaling Scrum program also provides metrics to measure the value generated by the approach selected for a multi-team Scrum Team project. As management monitors the metrics, the techniques can be adjusted to increase the value of the results. You may find it useful to read how to measure how effectively you scale your scrum effort prior to attending the workshop. Learn more.
Ken Schwaber's Blog: Telling It Like It Is 
Ken, You seem to be the man-in-the-know on the topic… I have succummed to the notion that I will need ‘certification’ in SCRUM and/or Agile to be seriously considered for some of the PM positions now being posted, even with 30+ years in IT and IT related project management. It is pretty merky water to wade in trying to determine where to get certified and who would be a good, and reasonably priced, training source for the certification. Going to the source…would you have a moment to offer suggestions pointing me in a good direction?
Find out if you are already in good shape. Take the Scrum Open assessment at Scrum.org (free). If you have problems, read the Scrum Guide (www.scrumguides.org) and then retake it.
Then ask me again.
Hi Ken, the sample test is not available from http://www.classmarker.com and they have asked to contact you.
Test are nice. It’s like gamification for reader. It encouraged me to read some more about scaling scrum. Thanks.
Ken – I appreciate this test and it helped me identify a few blind spots in my understanding of Scaling Scrum. I got above average on my score, but not as high as I thought I should have, which got me thinking in particular about why I got the question about branching / merging wrong – it seemed cut and dry. Your use of the word “sufficient” in that question led me to draw on my own experiences where that kind of strategy and supporting tool were absolutely sufficient, albeit not optimal, to deliver working software with multiple teams contributing to mainline. However, in the Scaled Scrum environment, that kind of strategy or tool alone cannot replace the human interactions of all team members that are working within the shared codebase. When applying the Scaled Scrum framework, I need to ensure that I don’t limit our implementation by what’s worked in the past, lest we end up with more “it’s always been like that syndrome”. We should establish a baseline and iterate at all layers of Agile Development, from daily up to sprint, release, and ultimately corporate strategy. Thanks for re-grounding me back towards the manifesto principles that I enjoy so much about being an Agile Professional and following your work.
I got really excited – normally not a poster…I did pretty well on the test. My faith in source control and concepts of system decomposition got me. But, I just want to thank you for the work you do – between the books and the PSM training you gave a couple years ago, I feel like we are of the same mind sometimes and my appreciation of Scrum increases almost daily. I still remember, and share something you said to me after the training, to paraphrase:
[Your job] is to demonstrate how you are going to get the team to show how brilliant they are.
Been using that a lot on my latest project despite not being in an Agile or Scrum environment from a PMO perspective.
Thank you again.
Cheers,
Josh
ps. That was the moment I knew coaching was definitely for me…still working on it.
So good, I can review my knowledge about scrum
Can anyone answer this question
Which case is not possible to scale agile
A) When there are not enough product owners
B) When there is more than 1 product
C) When there is a shared backlog
D) When you need more than 9 developers
I think it is A
i think its B, scaling is having multiple teams for a single product.
Pingback: Studying for the PSM II exam – Thoughts on Software Management and Development
I have a problem with access to the test. There is information that it is no longer available (date and time restriction). Can you check that for me? Thanks!