Scrum.org Professional Scrum Product Owner (PSPO I) Assessment Study Tips

  1. Read and thoroughly understand/internalize the Scrum Guide. Read it several times in different sittings. We recommend that you download the PDF and read it like you would a book. Over, and over again!
  2. Take the Scrum Open assessment numerous times. Get to where you can take it 5 times in a row and score 100% each time, in about 10 minutes or less each time. VERY IMPORTANT – DO NOT SKIP THIS STEP.
    • Yes, we know there are a lot of repeat questions, but you will need to be able to quickly answer these questions when the time per question is much shorter on the real assessment.
    • For each question that you miss, read the feedback given by the assessment on that question. Then, look in the Scrum Guide for specific language OR just Scrum principles and concepts that support the correct answer. Analyze what makes all of the other (wrong)answers seem inferior.
    • In between “5 times in a row sessions”, read the Scrum Guide again.
    • Do not assume that the real assessment is of the same difficulty level as the practice assessment. The real assessment is definitely harder.
    • If you find you are completely stumped, post a question on the Scrum.org forums.
      • Note that posting Scrum Open questions is fine, but do NOT post real assessment questions on the forum — that is against forum rules.
  3. Repeat step 2 above, except taking the Scrum Product Owner Open assessment. VERY IMPORTANT – DO NOT SKIP THIS STEP.
  4. Repeat steps 2 and 3 a few times spread out over a few days.
  5. Read about Burndown Charts here and here.
  6. Warning: There are 3rd party companies (i.e. outside of Scrum.org) that provide practice tests and test preparations for this assessment. In our experience, while they are mildly helpful, they will steer you so wrong on the understanding of Scrum sometimes that we recommend against even considering them. We recommend you definitely don’t use them to prepare.
  7. Read the Scrum Glossary, and refer back to it when necessary.
  8. If you took a Scrum.org class (which is quite helpful, but not required), review the slides, workbooks, your notes, etc from that course.
  9. Read this article a couple of times: The New New Product Owner
  10. Read the EBMgt Guide, focusing in on the EBM Key Value Measures that can help a Product Owner assess and understand value.
  11. Follow this advice:http://scrumorakel.de/blog/index.ph…ments.html
  12. When taking the test, scribble a few notes about questions that took you a long time to answer or you felt like were very challenging. This will help you to study in case you need to re-take the assessment later. Remember that you can re-take the assessment for only $200 more. Go here to purchase another attempt if you like.
  13. Assume that there are no “perfect” answers… Only “best” answers — when wearing your “Scrum Principles Wizard” hat. Answer as if you were the author of the Scrum Guide yourself.

If you have several weeks or months to study, OR no Scrum experience…

If you have a more extended period of weeks or months to study, OR you don’t have much actual experience using Scrum, then we also recommend:

  1. Purchase and read the Scrum Pocket Guide
  2. Read and follow the Scrum.org forums. Pay close attention to those posters who seem very knowledgeable or have a high number of posts shown under their user name on the forum.
  3. Read some or all of the resources suggested by the PSPO Subject Areas

When You’re Ready…

When you’re ready to take on the assessment, use the complimentary attempt you were emailed by Scrum.org as a result of your attendance in the class. Or, if you didn’t attend a Scrum.org class,go here to purchase another attempt . It’s that easy!

Other Useful Links

Thinking of taking the Professional Scrum Master (PSM I) assessment at Scrum.org? See here for study tips for that assessment.

Advertisements

Scrum.org Professional Scrum Master I (PSM I) Exam Study Tips

  1. Read and thoroughly understand/internalize the Scrum Guide. Read it several times in different sittings. We recommend that you download the PDF and read it like you would a book. Over, and over again!
  2. Take the Scrum Open assessment numerous times. Get to where you can take it 5 times in a row and score 100% each time, in about 10 minutes or less each time. VERY IMPORTANT – DO NOT SKIP THIS STEP.
    • Yes, we know there are a lot of repeat questions, but you will need to be able to quickly answer these questions when the time per question is much shorter on the real assessment.
    • For each question that you miss, read the feedback given by the assessment on that question. Then, look in the Scrum Guide for specific language OR just Scrum principles and concepts that support the correct answer. Analyze what makes all of the other (wrong)answers seem inferior.
    • In between “5 times in a row sessions”, read the Scrum Guide again.
    • Do not assume that the real assessment is of the same difficulty level as the practice assessment. The real assessment is definitely harder.
    • If you find you are completely stumped, post a question on the Scrum.org forums.
      • Note that posting Scrum Open questions is fine, but do NOT post real assessment questions on the forum — that is against forum rules.
  3. Read about Burndown Charts here and here.
  4. Read the Scrum Glossary, and refer back to it when necessary.
  5. Pay special attention to the language in the Scrum Guide regarding the “Sprint Goal” and the “5 Scrum Values”.
  6. If you took a Scrum.org class (which is quite helpful, but not required), review the slides, workbooks, your notes, etc from that course.
  7. Warning: There are 3rd party companies (i.e. outside of Scrum.org) that provide practice tests and test preparations for this assessment. In our experience, while they are mildly helpful, they will steer you so wrong on the understanding of Scrum sometimes that we recommend against even considering them. We recommend you definitely don’t use them to prepare.
  8. Follow this advice:http://scrumorakel.de/blog/index.ph…ments.html
  9. Follow this advice:http://webgate.ltd.uk/how-to-pass-the-professional-scrum-master-i-psm-i-assessment/
  10. When taking the test, scribble a few notes about questions that took you a long time to answer or you felt like were very challenging. This will help you to study in case you need to re-take the assessment later. Remember that you can re-take the assessment for only $150 more. Go here to purchase another attempt if you like.
  11. Assume that there are no “perfect” answers… Only “best” answers — when wearing your “Scrum Principles Wizard” hat. Answer as if you were the author of the Scrum Guide yourself.
  12. Purchase and read Hiren Doshi’s Scrum Insights for Practitioners Book. (While this book is not perfect, there is a ton of awesome info in it and it is far better than any other book on the market to help you learn Scrum and prepare for this test.)

If you have several weeks or months to study, OR no Scrum experience…

If you have a more extended period of weeks or months to study, OR you don’t have much actual experience using Scrum, then we also recommend:

  1. Purchase and read the Scrum Pocket Guide
  2. Read and follow the Scrum.org forums. Pay close attention to those posters who seem very knowledgeable or have a high number of posts shown under their user name on the forum.
  3. We suggest attending and engaging in Scrum user groups and conferences – go there, listen to people describing their challenges, and then think of how empiricism and self-organization, as described in the Scrum Guide, would suggest approaching the challenge. If the answer is not clear, post the scenarion and the options you can think of, on the Scrum.org forums and take a look at the responses you get.
  4. Read some or all of the resources suggested by the PSM Subject Areas.

When You’re Ready…

When you’re ready to take on the assessment, use the complimentary attempt you were emailed by Scrum.org as a result of your attendance in the class. Or, if you didn’t attend a Scrum.org class, go here and purchase an attempt. It’s that easy!

Other Useful Links

The New Definition of Software Success

In a previous post on why large scale Agile and Scrum is 6X more successful than waterfall, I explain how Agile projects/products are so much more successful than waterfall based approaches like the Rational Unified Process.

What is also equally important to note, is that the Standish Group, an industry leader in the software project management survey field, has changed their definition of success.  According to Jennifer Lynch from the Standish Group:

The Standish Group has redefined project success as onTime, onBudget with a satisfactory result…we have seen many projects that have met the Triple Constraints [schedule/scope/cost]and did not return value to the organization or the users and executive sponsor were unsatisfied.

It’s important to note that this definition changed in 2015, and the definition is applied equally across waterfall and Agile projects at The Standish Group.

A parallel development also captures this trend.  Scrum.org is an industry leading organization focused on improving the profession of software delivery through Agile approaches like the wildly popular Scrum approach (some 90% of software teams use Scrum). Scrum.org has now publicly released a new software success metrics model that they call “Evidence Based Management for Software Organizations(tm)“.  The approach is mostly public, with the one minor exception of one value based formula that can only be obtained from engagement managers licensed by Scrum.org to do so.  The other 95% of the approach is described here in this whitepaper, and just knowing the basics of the approach can help any organization improve.  In it, Scrum.org has identified 11 key software metrics that can be used to trend whether your software investment ROI is heading in the right direction or not.  What’s important to note is that these 11 key metrics are all just more detailed derivative metrics of, you guessed it: schedule, scope, and customer/user satisfaction.

So, the clear trend from the above two developments from industry thought leaders is that we in the software industry should take notice on how we evaluate the success of software projects.  The data strongly indicates that we have been focused on the wrong success metrics for the past 50 years in our industry.  It appears that schedule/scope/cost is now passe in the industry. It’s time to begin focusing on value delivery via the key metrics of schedule/satisfaction/cost.

Large Scale Agile and Scrum vs. Waterfall: Agile is 6X More Successful, 1/4 the Cost, and 10X Faster Payback!

A pair of recent findings from the Standish Group confirm the astonishing success and cost savings of Agile approaches over waterfall.

In the “Chaos Report 2015“, Standish found that large Agile projects are 6X more successful than waterfall projects.  While Standish doesn’t get specific on what is a “large” project, it’s worth noting that “Large” is the biggest size category for projects and their data encompasses over 10,000 software projects.

In a new report called  The Money Pit, The Standish Group studied two very similar large software projects, done at two very similarly sized, mature companies.  One project was done with Agile, and one with Waterfall.  The astounding results they found:

  • The Agile project was 4X cheaper than the cost of the equivalent waterfall project, AND
  • The Agile project was “delivered with high user satisfaction,” while the waterfall project “had a watered-down critical function and the high-value feature was not part of the delivered application.”, AND
  • The Agile Project’s payback was “At the end of two years the application costs were fully paid back and the users were highly proficient” while the waterfall organization estimated the system payback would “break even in 20 years”
 
* Note that the activities depicted on the graph were done sequentially via waterfall, but iteratively via Agile.

It should also be noted that a survey from Forrester Research showed that of all companies attempting Agile, some 90% are using Scrum.

Just to re-iterate — 6X more successful, cost payback 10X faster, and 4X cheaper.  How is that for Better, Faster, Cheaper?

At AgileSoftwareTraining.com, we provide coaching, consulting, and training solutions to help your company achieve the astounding success of Agile and Scrum approaches.  Contact us today for a free consultation.

So, if you’re an organization that is doing waterfall or struggling with Agile, what are you waiting for?  The research is overwhelmingly in favor of Agile and Scrum approaches.  Get on the road to millions more in profit and cost savings.  No seriously, what are you waiting for?

The New New Product Owner: The Product Visionary

In my previous post, I discussed the New New Product Owner as The Product Marketplace expert.  In this post, we explore the “Product Visionary” focus area.

The Product Owner is the chief product visionary. The PO should be able to clearly articulate the product vision to the Scrum Team and key stakeholders, and how that vision aims to maximize the value of the product and of the work the Scrum Team performs.
POFocusAreas_NewNewPOThe PO should communicate and re-iterate this vision early and often, reminding all involved of how to help maximize value.

For a high quality class that focuses exclusively on the Product Owner role(the course is also great for key stakeholders!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.

Utilizing the underlying empirical product planning features of Scrum, the PO should also be ready to make strategic pivots for the product vision whenever there are significant changes in how value can or likely be captured. This vision is brought to life in a more tactical way, via the Product Backlog and iterating towards that vision every Sprint.

In my next post, we’ll discuss the New New Product Owner as the Release Decision Maker.

A Response to Mike Cohns Comments on 64% of Software Features Rarely or Never Used

I have a saying.  “Scrum Trainers usually agree on 99% of Scrum, but they spend a lot of time debating the other 1%.”

Let me say this first.  I’m a huge fan of Mike Cohn.  I teach Scrum and Agile classes all over the country at Fortune 50 companies, and it is very rare for a class to go by that I won’t mention at least one of his awesome books on Scrum.  I also recommend him on my list of favorite Agile resources on one of our web sites.  In addition to all of this, I’ve had numerous personal interactions with Mike one on one, and he’s always been extremely nice to me, traded professional practice opinions/advice, and he even offered to let me attend one of his classes at a “trainer courtesy” discount one time.  Great guy!  In summary, I like the guy a lot personally, and I highly respect him professionally.  He’s done a ton for the software and Agile industry, and no one should forget that.

So, with that said, let’s get back to that 1% debate.  🙂

In his recent blog post, Mike reveals some little known details about the oft cited 64% of features that are rarely or never used in software systems.  His information is factual and likely true.  I’m ok with all of that.

What I don’t understand is, why bother broadcasting this?

This is one of the most credible studies available on the subject.  If you think hard about this data for a minute, you’ll realize why it is incredibly difficult to obtain… No company wants to admit that there is a TON of bloat in their software!  But, what percentage of Microsoft Excel/PowerPoint/Word features do you use and benefit from?  What percentage of Rally features do you actually use and benefit from?  Bloat bloat bloat, negative value, negative value, negative value.   In my recent articles on the New New Product Owner, I’ve talked about the need for the New New Product Owner to be a marketplace expert, so that they can maximize the value and profits from software development for their company.

Now, the value equation is way more complicated than “rarely or never used”, but still, I think we all know that there is a TON of negative ROI functionality in any non trivially sized application, and there is a TON of software teams with far too little focus on value and profits.  Anyone who has worked on the front lines of software development knows that.  The oft cited study just helps confirm some of our suspicions.  One of our Agile Metrics consulting services at AgileSoftwareTraining.com is helping to give company leaders even more transparency into how to extract more profits and cost savings out of all of their software development efforts, whether they be internal or external systems.  Give us a call if you’re interested.

What makes that limited study useful as a teaching tool is it gets people to think about value, and think about low value, low ROI features, and realize that value delivery is important, far too important to ignore.

Newer Study confirms the same idea!

Further, Standish again re-iterated this point in 2014, ostensibly from wider data: https://www.standishgroup.com/sample_research_files/Exceeding%20Value_Layout.pdf — “Standish Group research shows that 80% of features and functions have low to no value.”

There are other “studies” cited in our industry that are totally bogus, software leprechauns if you will, and I’m totally against relying on those.  Things like the “Cone of Uncertainty” and the so-called “Weinberg study” on task switching have shown to be totally made up.  However, the Standish Group study is real, with real data, and it is highly credible, even if somewhat limited in its scope.

So, Mike wants us to stop citing the study, or for us to caveat it with “in the weeds” details.  Of course, that will just confuse those new to Scrum and the teaching value would be lost.  And people would focus less on software value and profits.  I don’t think that’s good.  I’m totally open to hearing about a more credible public study, but I’m unaware of one. 

With all due respect to a friendly colleague, and one of the best Scrum trainers on the planet, I think ignoring or caveating the 64% study is bad for the industry.  Let’s just put this in the 1% bucket that we as Scrum trainers will agree to disagree on.  🙂

If you’d like to disagree with my contrarian view, feel free to sound off in the comments below!

Scaling Agile and Scrum to multiple teams: Great Overview of LeSS and Large Scale Scrum

If you’re like many companies out there, you’re trying to figure out a way to effectively get multiple Agile teams to work together to deliver more with less.  Well… Let me introduce you to LeSS — Large Scale Scrum.  Large Scale Scrum has been in practice since 2005.  The co-creators of LeSS, Certified Scrum Trainers in their own right, have just released a kick arse chapter from their new book on LeSS.  Their chapter, in my opinion, is the best introduction to LeSS for those who are not familiar with it.  I highly recommend you give it a read!

If you’re interested in learning more about Large Scale Scrum (LeSS), check out the LeSS class being held in Denver in late September. (Includes certification, SEU’s, etc)

Here is the link for the chapter introducing LeSS:  http://less.works/less/framework/introduction.html

%d bloggers like this: