I may be asking a question that many of you would have had before you passed the PSM-1 exam.
I have been preparing for the PSM-1 certification exam for last 2 weeks.
- Have read the scrum guide few times.
- Have been giving open assessments daily and scoring 100% (95%) constantly.
- Have even given the suggested practice test Mikhail Lapshin website (result is 100% last 3 attempts).
Am I ready to give the certification exam or should I continue to given the same practice tests more? How do you know if you are ready to sit for the exam? I know it is recommended that one should understand the concepts than cram the scrum guide but it is not easy to assess your understanding.....there are not many practice tests available to assess how the situational questions would be...so guess it is more like - give the exam & see whether you pass.
Are there other mandatory resources I should study/refer other that scrum guide that are a must to read before the exam? Are the real test questions similar to open assessments or are all situational?
Note: There are concepts in the Scrum guide that honestly don't make much sense to me when I read them (they look good on paper but it's difficult to imagine that in real projects it would be possible to implement them) but I will ignore that presumption for now to focus on the exam. I can guess, scrum is easy to understand but difficult to master is said for a reason :)
Based on your preparations to date, I'd say you are ready for the PSM I. I just had a copy of the Scrum Guide handy and did the free practice questions they had on the scrum.org site, but I relied on my many years of experience working with agile teams so as long as you have experience in applying the concepts within the Guide you should be fine.
Kiron Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
If you feel comfortable with the recommended resources, then go for it. Otherwise, continue preparing. Typically, those with some relatable experience sit for the certification, so without field experience to lean on, some concepts may remain elusive.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Mohit
I agree with Kiron in that given your description, you seem very ready. It took me two days to prepare for this exam but I’ve had past experience with Scrum.
In the scrum guide, they mentioned that scrum is easy to understand but difficult to master and that’s true.
The challenge in the exam is not the material but the fact that you have to answer 80 questions in 60 minutes and achieve 85% so your margin of error is low and time frame is narrow. You need to be mindful of this in the exam.
The exam questions are not so straight forward so make sure you understand the concepts because given the time limit, you won’t have time to research for the most part.
I really appreciate all your inputs and suggestions but I am planning to put the PSM certification on hold for now. I surely can go for it but I would rather wait until I fully understand what I am reading :)
As I read more on Scrum, I find it hard to imagine how it would be possible to use in real world. The defined concepts in the Scrum guide are very vague (wrapped under the term "flexible"), leaving it for individuals to interpret & implement them.
Quick example: It's easy to state on paper that the development team is responsible as a whole for the work in Sprint but in reality when checking on progress (which again only the dev team is doing using daily scrum - why?), how can this be managed?
Having obtaining PMP (which I found to be very well defined and each of the 49 processes well connected to provide a logical approach to delivery), reading on scrum is not making sense to me....
I know Project Management & Scrum is not a right comparison as Scrum is more of a product management framework and I am not doubting the framework, maybe I need to read more & gain more practical exposure to understand the benefits of Agile mindset.
...
1 reply by Jared Padgett
Jul 16, 2020 7:36 PM
Jared Padgett
...
Mohit,
The main point to remember is that agile teams focus on delivering the most value. What is considered valuable can and does change over time, so an agile team is able to respond to changes and continue delivering value. A traditional team might get caught up on sunk costs, issues with refactoring, or other constraints that ultimately ends up in delivery of a worthless product.
The Development Team is a self-managing team. They are able to identify the work that needs to be done, and since they are doing the work, they understand the complexities of the job better than a traditional hierarchy.
This does not mean that they are detached completely from the organization, though. The Product Owner is in touch with the business leaders and the customer (whether that customer is internal or external). The Product Owner identifies what would create value, in collaboration with the Development Team, Management, and the Customer. The Development Team then focuses on delivering the value.
This makes the most sense in the context of software development, which is where these ideas emerged. However, the framework can work in other more traditional industries. Removing micromanagement from the equation empowers teams to deliver value.
Saving Changes...
Jared PadgettVerizon MediaVentura, Ca, United States
Jul 16, 2020 6:48 PM
Replying to Mohit Joshi
...
All,
I really appreciate all your inputs and suggestions but I am planning to put the PSM certification on hold for now. I surely can go for it but I would rather wait until I fully understand what I am reading :)
As I read more on Scrum, I find it hard to imagine how it would be possible to use in real world. The defined concepts in the Scrum guide are very vague (wrapped under the term "flexible"), leaving it for individuals to interpret & implement them.
Quick example: It's easy to state on paper that the development team is responsible as a whole for the work in Sprint but in reality when checking on progress (which again only the dev team is doing using daily scrum - why?), how can this be managed?
Having obtaining PMP (which I found to be very well defined and each of the 49 processes well connected to provide a logical approach to delivery), reading on scrum is not making sense to me....
I know Project Management & Scrum is not a right comparison as Scrum is more of a product management framework and I am not doubting the framework, maybe I need to read more & gain more practical exposure to understand the benefits of Agile mindset.
Mohit,
The main point to remember is that agile teams focus on delivering the most value. What is considered valuable can and does change over time, so an agile team is able to respond to changes and continue delivering value. A traditional team might get caught up on sunk costs, issues with refactoring, or other constraints that ultimately ends up in delivery of a worthless product.
The Development Team is a self-managing team. They are able to identify the work that needs to be done, and since they are doing the work, they understand the complexities of the job better than a traditional hierarchy.
This does not mean that they are detached completely from the organization, though. The Product Owner is in touch with the business leaders and the customer (whether that customer is internal or external). The Product Owner identifies what would create value, in collaboration with the Development Team, Management, and the Customer. The Development Team then focuses on delivering the value.
This makes the most sense in the context of software development, which is where these ideas emerged. However, the framework can work in other more traditional industries. Removing micromanagement from the equation empowers teams to deliver value.
...
1 reply by Mohit Joshi
Jul 16, 2020 7:59 PM
Mohit Joshi
...
Thanks Jared for the perspective.
No micromanagement is indeed a positive, but 100% empowerment of the development team is not. From selection of items -to estimate-to performing actual tasks-testing-to delivery of increment, all at the discretion of the team doesn't make sense. We are relying heavily on the entire team to be super skilled, honest (not pad the estimate, accept mistakes..) and disciplined. I think in reality this is quite hard to expect. Plus, making the whole team accountable for outcome would make it difficult to identify & correct the weakest link in the chain, that may slow down the velocity. I think there has to be a balance.
Having said that, I am still trying to get my head around it :)
The main point to remember is that agile teams focus on delivering the most value. What is considered valuable can and does change over time, so an agile team is able to respond to changes and continue delivering value. A traditional team might get caught up on sunk costs, issues with refactoring, or other constraints that ultimately ends up in delivery of a worthless product.
The Development Team is a self-managing team. They are able to identify the work that needs to be done, and since they are doing the work, they understand the complexities of the job better than a traditional hierarchy.
This does not mean that they are detached completely from the organization, though. The Product Owner is in touch with the business leaders and the customer (whether that customer is internal or external). The Product Owner identifies what would create value, in collaboration with the Development Team, Management, and the Customer. The Development Team then focuses on delivering the value.
This makes the most sense in the context of software development, which is where these ideas emerged. However, the framework can work in other more traditional industries. Removing micromanagement from the equation empowers teams to deliver value.
Thanks Jared for the perspective.
No micromanagement is indeed a positive, but 100% empowerment of the development team is not. From selection of items -to estimate-to performing actual tasks-testing-to delivery of increment, all at the discretion of the team doesn't make sense. We are relying heavily on the entire team to be super skilled, honest (not pad the estimate, accept mistakes..) and disciplined. I think in reality this is quite hard to expect. Plus, making the whole team accountable for outcome would make it difficult to identify & correct the weakest link in the chain, that may slow down the velocity. I think there has to be a balance.
Having said that, I am still trying to get my head around it :) Saving Changes...
Community Champion
