Tips for PSD I accessment
I see there are very few discussions on PSDI assessment in the forum, so I decided to raise this topic and hopefully it will help people who are also interested in the PSDI assessment as me.
I passed my PSDI assessment with 92.5% score last night, without attending any training or classes prior to the test, and it took me around 1 month time to prepare the test - interestingly this is exactly the time box for a sprint. So let's make this as a project which contains only one sprint. The sprint goal will be to pass the PSDI assessment. Let's now talk about what are the PBIs and sprint backlogs in order to successfully deliver the incremental or the full project by the end of one month.
1. Scrum open assessment and developer open assessment - top priority
The Scrum open assessment and developer open assessment are extremely extremely useful, I can not emphasis more on this. Not only some questions in the open assessments will be in the final test, but also it helps you to get an idea what will be the topics covered in the final test. You must constantly pass these two assessments with 100% score, but that's still not enough. Learning by rote will only help you when the exact same question appears in the final test, but what if the question changes it's format? You must understand fully why some options are right and why some options are wrong. For example, one term called Cycle time per feature related to code quality, when this team appears in one of the developer open assessment question or options, you will need to check what exactly does it mean and how it related to code quality.
2. Scrum guide - top priority
This guide (English version) is THE document that must be read multiple times if not once per day. You must understand word by word, phase by phase of the entire document. Pay special attention to the responsibilities. i.e. who should do what.
3. Professional Scrum Developer Subject Areas - secondary priority
Previously this page contains key words for testing topics but suddenly those key words are gone from the page. Those key words were useful for reading the recommended books. I would not recommend you to read the full list of the books - that's too many! If you want to read all those books within 1 month time I have to say this is a poor sprint planning result. Keep concentrate on a subset on them. For each area select at most one book to read, there will be questions in the assessment for code quality, testing driven development, continue integration and automatic build, refracting, etc, so make sure you read all related topics and materials. When reading books pay special attention to new terms, what does it mean? what is it's pros and cons? when and where to use it? You don't need to spend too much time on instructions on specific tools or coding languages. The assessment will only address the concept of the terms but not how it is implemented by specific tools and coding languages.
4. Scrum.org forum - third priority
In the forum people discuss various topics/questions about Scrum and assessment, it worth to check out the forum for useful piece of information and put it in your study list.
Once you have all those PBIs "done" and the sprint review is coming. you want to demonstrate the shippable product to yourself by taking the assessment test. Here are some tips during the test.
1. Although time is limited for 80 questions within 60 minutes, I found I still have time to go back and review my answers. In fact, I spend only less than 40 minutes to finish all those questions. The key is for questions with uncertain answers, don't spend too much time on it for the first time. Choose whichever your instinct tell you to choose then bookmark this question and proceed to the next one. Once all questions are finished open your bookmarked questions and review one by one. This time you may want to spend more time on those tough questions because you know you have finished answering all the other questions so you are more relaxed to spend time on it. The bookmark question is a very useful tool so use it wisely.
2. I found the most tough questions are those with multiple correct options but without limiting how many correct options. For those kind of questions it worth to take some time on them and make sure you don't mistakenly select one option you actually don't want.
Now you feel you are ready for the test. Prepare one hour quiet time for this, get your wife to take care of the kids, prepare a cup of coffee or tea although you will not have time to drink, take a bath, make yourself relax while you seat in your chair and comfortably open the assessment page, do it!
The last event in our sprint - the Sprint Retrospective, maybe not be needed if you pass the assessment, but it will still be useful for you to review your PBIs to see what made you success, and for the questions in the test that you are not uncertain about the answer, it's a good opportunity to review the supporting materials to find out the answers. For me, the Sprint Retrospective results are all included in this post. For people who fail to pass the assessment, this Sprint Retrospective is a must to figure out what went wrong in your sprint and what should be done to improve it.
At last, one thing I want to suggest to the Scrum.org. The bookmark tool is useful in the test but when I open the bookmark page, I see only the question numbers and an indicator to show whether the question is bookmarked, it would be more informative if the table can contain some short description of the question or even the question itself without the options. This will greatly help the testers to choose which question to review.
I have a question about one of the PSD study areas: Emergent Architecture. I looked at the suggested readings. The materials are either very vague or seriously outdated. Do you have any tips on the key things I should know for this study area?
Here are 2 key principles to bear in mind regarding architectural emergence in Scrum:
1) Architecture emerges as a collaborative effort of the whole team; there is no architect role.
2) Each sprint must always deliver a potentially releasable increment of value. While it's reasonable for certain sprints to focus on architectural matters, some value must always be delivered, even if it is just one or two PBI's which validate architectural assumptions.