Struggling against questions not Scrum
After attending PSMI class with Gunther at Brussels I tried the PSMI again and scored only 94% (I had 96% before)
This result pissed me off. But more than that, I understood that I was really fighting against the questions, and not my Scrum knowledge leaks. Some of the questions were SO not clear that I could hardly tell what they really asked. Maybe that is due to the fact that I'm not a native english speaker and maybe I don't get a full range of tiny details in questions, maybe something else. But this is really annoying. Let me give a few samples:
1)A very simple question:
During Daily Scrum, the scrum master's role is:
teach the Dev. Team to keep the time box
The questions is extremely easy, BUT from Scrum Guide we learn that SM is optional for Daily Scrum.
So both facilitating discussions and teaching to keep the time box would be right options IF SM attends the Daily Scrum. In case he doesn't - only teaching to keep the timbox is valid. So what would be a right answer?
2) The question:
The purpose of the Sprint is to have a working increment of product done before the Sprint Review.
From Scrum Guide we learn that it's "potentially releasable increment" that Dev. Team has to deliver by the end of the Sprint. Does it mean that we can't call it just "working" in a question and thus it's wrong or? There's some strange ambiguity here.
3) Another question:
The primary reason one might choose a four-week Sprint is when the work is too large for a two-week Sprint and cannot be decomposed further.
Again, strange formulated questions... the work PRIMARY. Who has the statistics available for validating this? Is there any research showing which is the primary reason for choosing 1 month Sprints. I don't think there's anything like that available. That's why I put false, though I understand it often happens. But what the bias behind this questions - no idea.
4) As quality assurance work does not occur as part of the development work in Sprint, which benefits are lost?
QA is not about testing, controlling and validating, but about Process and improving. Thus, QA is performed during Retro each Sprint by the Scrum Team. On the other side- Quality Control is about testing and controlling the quality of the Product (not the Process). Looking at the possible answers - I could say that the answers really meant Quality Control (testing) and not Quality Assurance. That really confused me.
5) Can a team deliver a single document by the end of the Sprint if this it's what the PO asked for?
What if DoD is compatible with it and so this is the releasable increment of Done product. Again, I was confused with this question and it doesn't say anything about what the DoD is for this team. Behind that, I guess that the Development Team should only deliver the releasable potentially shippable increment of Done product by the end of the Sprint. And SM is to remind about this to the PO.
6) A Sprint Review is the only time the stakeholders and the Scrum Team meet together? Again, formally yes, because "during Sprint review the Scrum team and stakeholders collaborate about what was done in the Sprint"
Any thoughts on this?
(Disclaimer: Ilya and I attended the same course with Gunther)
It's been a year since I first took the PSM I and what I've learned in the intervening year is that Scrum is not black and white. It has many shades of grey. This makes it more difficult, in my view, to answer some questions as they require the fundamental knowledge of Scrum, without experience clouding the question.
To address some of your points:
1. "The questions is extremely easy, BUT from Scrum Guide we learn that SM is optional for Daily Scrum.
So both facilitating discussions and teaching to keep the time box would be right options IF SM attends the Daily Scrum. In case he doesn't - only teaching to keep the timbox is valid. So what would be a right answer? "
To me, of the two options you propose, the right answer would be "Keep the timebox." The reason is that I don't think the ScrumMaster has a role in facilitating discussion at the Daily Scrum at all. Quite the contrary. We often have to remind ourselves to NOT get engaged as the Development Team update each other. But then, this could be my experience clouding the question :)
2. I think the phrase "potentially releasable" simply means that the Development Team have met the Definition of Done. That there is no other work remaining. That the PO could release the product if they chose to do so. Therefore, the phrase from the question: "working increment of product done" seems to me like it means the same thing.
I'm unclear on what you're asking in the paragraph about QA?
3. The question "Can a team deliver a single document by the end of the Sprint if this it's what the PO asked for?" I think the answer is "Yes" (especially if the question makes any reference to delivering value to the organization). I don't believe the DoD is intended to apply to every Product Backlog Item that may be worked on, especially when we recall that PBI's can refer to Functionality, Defects, Non-Functional Requirements etc.
4. "A Sprint Review is the only time the stakeholders and the Scrum Team meet together?" I wouldn't agree with this. There's is nothing to stop the PO, for example, from requesting stakeholders to attend a Product Backlog Refinement session where doing so would aid the Development Team.
Hope the above helps and I'd be very interested in reading anyone else's views on the above and Ilya's initial questions.
Derek, I also don't believe that DoD should apply to every PBI in a Backlog. DoD is applied to the Increment.
But I'm convinced that each Sprint the Team should bring at least a small piece of functionality - otherwise you won't have any Increment.
I you bring only document by the end of the Sprint - the question is "where is the Increment"?
I think it may have to do with the perspective of the document.
If the product under development was a complex legal reference title, then it's easy to see how a document produced during the Sprint would be an increment.
But equally, one of the requirements for a piece of software could be a complete help / guide document so again, this would be an increment of the product.
At least, that's the way I'm looking at it.
Hi, I'm a Scrum newbie, but I found this discussion interesting.
Here's my take:
1) The question is written in a way ("During") that implies for me that in this particular case the SM is attending. But should he "facilitate" discussion? I'm not a native English speaker but they way I've understood it is it means he helps keeping discussion flowing without actively participating with it (regarding content) so the answer would be correct. But the timebox is definitely more important.
2) I'm with Derek here. "working" can mean the product can be released.
3) That's awkward for sure. There's a similar question in the open assessment where the correct answer is "false" but the word "primary" is missing there AFAIK. I guess this was part of research work done by the Scrum heads and could be documented somewhere, maybe in "Software in 30 days" which I haven't read.
4) To be honest, the phrase "quality control" is new to me. I've always used "QA" for what you described as quality control: writing and documenting tests, making reports of their outcome. The questions doesn't seem to be very Scrum oriented to me, it's more about the software development process. Eventually they want to emphasize that the sprint includes all SW development tasks (from design to testing) in a single iteration.
5) Well, If the product is the document itself, it makes sense. The question sounds like it (the team delivers the document, apparently nothing else). I don't find this particularly clear, though.
6) The PO belongs to the team and he can be in permanent contact with the stakeholders..., so "no". Actually I think that's part of a whole series of questions that want you to answer "inspection and adaption can happen anytime", only adapted to different cases.
I just took PSM I and promptly ran into your 1), so I want to make additional comments. The presented answers forced me to reconsider because one of them was "ensures every dev team member answers the three questions" which would mean the SM has a more active role as I was willing to allow him. So I finally settled on the "timebox" answer instead of choosing "all answers", because it was that prominently placed in the Scrum Guide.
However, I don't have 100% so that could've been one of the questions I answered wrongly.
One irritant is that there was no feedback at the end of the test which would give me a list of my wrong answers. Quite unlike other certification bodies for Scrum
Fortunately there is more to Scrum than only what is literally described in the Scrum Guide. And, still, the Scrum Guide does describe important behavior and principles and is therefore quite a rich document, despite the limited #pages.
Think also in terms of how Scrum respects and implements the principles of the Manifesto for Agile Software Development. One of them says that the primary measure of progress of working software. Where would we end up if we start accepting again that a document is enough, and the absence of a working piece of software is good?
@Gunther Great, I didn't believe that delivering a single document is possible.
Every Sprint we should find ways to deliver at least a small piece of functionality.
Same even for the very first week - when we setup environment, prepare the future requirements - at the end we should show an increment. Even if it's tiny.
Nice to see you on the Scrum.Org forums. Allow me to share some of my thoughts…
Its been a while since I took the assessment, so I’ll try to remember what I can. There are also some great comments by others, so I am offering some different examples.
For (1) –
We know that the SM is not needed at the Daily Scrum. This implies that anyone from the Dev Team can facilitate. Here’s what I thought -- perhaps the SM can schedule a 15minute meeting using people’s calendars.
For (2) --
I agree with you. i.e. “potentially releasable increment” – my interpretation for this is that not every Sprint backlog item may be done, by the Review.
Also, when talking about “Sprint 0” (which we know isn’t recognized in Scrum), I hear instructors mention that its better to have a little bit of the increment, rather than just analysis, etc.
For (3) –
I don’t recall the question and am a bit unsure whether I follow you completely.
I’m unsure whether its about statistics. I think its simply about the flexibility of the framework, where the max is 4 weeks.
For (5) –
Here’s how I thought about it – the PO orders the backlog items and the Dev Team pull it into the Sprint backlog. They are not taking on the risk of ROI, amongst other items which is the responsibility of the PO.
Also, think of it this way – the DoD may not have evolved or mentioned anything about documentation (poor, in my opinion and would evolve). Furthermore, perhaps this was a shorter Sprint near the holidays or where there were some unusual circumstances so the team may have suggested to work on documents, instead of heavy coding and the PO agreed.
Also, consider that perhaps some Sprints have passed and a future Sprint has a focus on documentation. Not good practice, in my opinion, as it reminds me of “hardening sprints” (not recognized in Scrum, again) – but it is possible and this *adds* to the increment.
For (6) –
There may be an opportunity for the stakeholders and the Team to collaborate even prior, as more is learnt or work emerges.
This was annoying to me as well.
However, I was pleasantly surprised at the quick turnaround when I reached out to the Support team and got some feedback. (Not exact questions, but which areas to focus on.)
May not be a perfect scenario, but just sharing in case you haven't considered this option.
@Illya @Gunther : This gives me pause for thought. Here's why:
Scrum is a framework for complex product development. It's not limited to software development (but lends itself to that really well).
The Agile Manifesto, which DOES limit itself to software applications states "We value working software over comprehensive documentation" and The Agile Manifesto principles, which DO limit themselves to software applications, states "Working software is the principal measure of progress" and "Working software is delivered frequently (weeks rather than months)"
So, in the question under discussion, (Can the Development Team deliver a single document at the end of a Sprint, if that is what the Product Owner asked for), if we use the Scrum as our guide, the answer is "Yes". If we use the Agile Manifesto, the answer is "No".
When taking the PSM I assessment, my view is that we're answering questions on Scrum. (ie: We're NOT limiting ourselves to software products)
Gunther: Your answer to Illya seems to say that this view is wrong?
I'm sure (and absolutely agree here with Gungher) that Scrum should respect and implement the principles of the Manifesto for Agile Software Development. Scrum is a reflection of Manifesto and though Scrum can be used outside the IT industry (as you, Derek said), we have to remember what it means to be Agile.
To be Agile means conform (don't like this word, but...) to Agile Manifesto values and Principles.
You can work without Scrum, but still be Agile if your process is respects Manifesto principles, but you cannot do Scrum if you don't implement Manifesto.
Scrum is primarily, but not exclusively, about the delivery of software. As such a release could consist of a document and no software at all.
Scrum could be used by magazine publishers, for example. Each Sprint (month) they could release a new issue (a document) which consisted of several user stories (perhaps articles or real stories) that satisfied the Product Owner (editor) met a Sprint Goal (the topic of the issue) and a Definition of Done that was agreed with the production team.
Let me complicate things even more :-)
Scrum, with its implementation of empiricism and as a 'new new product development game', can be applied on any type of complex product development situation.
However, the Scrum framework as we know and teach it, has been optimized for software development. Software development is the natural habitat of Scrum.org and most of its community members too. I can't judge whether the way we describe the rules, the accountabilities, the meetings, etc. are just applicable in other domains without tweaking them to that context.
> I can't judge whether the way we describe the rules, the accountabilities, the meetings,
> etc. are just applicable in other domains without tweaking them to that context.
I doubt anyone can really do that. Just look at the cases we have in software development where clients tell us that "Yes we are sort of doing Scrum, but Scrum can't work that way here because..." or "We are special here because..."
Now try applying Scrum outside of the IT sector, where we face domain experts who can cite their own "special" cases, and for which we can have no ready and knowledgeable answer. If a surgeon tells me "Scrum can't work that way here because..." I'd be less confident than if I was facing a belligerent IT department head with 20 years of dysfunction under his belt
What I do know is that once you open people's eyes to their current process, and get them to question their established culture and practices, then Scrum usually becomes achievable...and without the tweaking (or butchering) of it.
Please allow me to reproduce the entire contents of the first question:
During the Daily Scrum, the Scrum Master's role is to:
a Facilitate discussions of the Development Team
b Ensure that each team member has a chance to speak
c Ensure that all 3 questions have been answered
d Teach the Development team to keep the Daily Scrum within the 15 minute timebox
e All of the above
As all i'm pendulating between last 2, but given my experience of SM, it doesn't help much if SM only assists and declares daily scrum over by the end of 15 mins. he should facilitate, so I would go with last one
We have had this before in the wording in this case its "ensure" in C&B, I would run with as a clue.
From the Q&A this is how i would approach it
A: Dev team should be self organizing, so should be able to do this as a team.
If they cant the daily scrum is ineffective, and SM service to Dev team is to facilitate for them.
B: This goes back to self organizing again if they need help the SM could do this as one of the services
It is not mandatory for it to be done at the stand up as the SM does not have to attend.
C: SM does not have to attend or "ensure", its the teams responsibility to do this with each other.
D: From the guide the daily scrum
The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
E: If you select this then you imply that the SM must "ensure" in C,B
That leaves D and A as more weighted from the guide as its true.
That is how i would approach it in the wording of the question, I know that SM has many responsibilities
Provides services to different levels, I could be wrong with this one so have given a reason why.
Others could share their thoughts on this one as some questions are tricky.
Very interesting topic.
I also share the same 'frustration' as others here.
I feel that the person who created the questions sometimes had some specific context in mind but could not completely reflect it in the question.
The Scrum Guide is sometimes a bit ambigiuous in my opinion.
To me, that's ok because it's a framework and shouldn't be too limiting.
However, when asking questions, there's only one right answer while in reality it might not be as simple.
Also, not learning from an exam is frustrating.
The minimal feedback you get is not in line with the goal/mission of scrum.org, one of which is 'teach people how to use Scrum'.
I agree with the poster. The PSM1 exam is shit.
in preparing for PSM I i keep coming back to this post, the questions i'm interested in are 5,6 stated by Ilya. here are some of my thoughts:
"5. Can a team deliver a single document by the end of the Sprint if this it's what the PO asked for?"
I think the real question here is: Is the produced document THE ONLY DELIVERABLE of that sprint? i mean that it doesn't state that its the only thing done by the team. If so, yes, the Dev team can deliver a single document, two documents, or no documents at all, if that's not part of DOD and not required by PO.
But let's assume the question would be like: "Can a team deliver a single document INSTEAD OF FUNCTIONALITY, by the end of the Sprint if this it's what the PO asked for?"
Page 10 in Scrum Guide says that in order to meet the Sprint Goal the Dev Team implements the functionality and technology. How does this explain the situation when the PO orders the production of a user manual as most valuable item and it takes an entire sprint for the team to produce it.
"6. A Sprint Review is the only time the stakeholders and the Scrum Team meet together"
The sentence is formulated so that it suggests that the A Sprint Review is the only time the stakeholders and the Scrum Team USUALLY meet together. In this case the obvious answer is True. But if they meant to ask if Sprint Review is the only possible time when Scrum team and stakeholders meet, they would have put it like "A Sprint Review is the only time the stakeholders and the Scrum Team CAN/MAY meet together.
Another point is: Scrum team as full composition, or only the PO as part of Scrum team?
1)A very simple question: During Daily Scrum, the scrum master's role is: teach the Dev. Team to keep the time box facilitate discussions other options...
I would go for teach the team to keep to the timebox
as you could only click 1 answer and it wasn't everything... scrum master doesn't have to attend daily, so he can't facilitate it if he's not there, but he does have to ensure that the scrum framework is followed, so that would only leave timebox.
2) The purpose of the Sprint is to have a working increment of product done before the Sprint Review.
I'd say yes as my idea of done means to have something working ie tested running and happy... which makes its potentially shippable
3 PRIMARY reason... umm agreed, answer would be false as I'm sure that lots of reasons could be why you have monthly sprint... just not sure which would be the primary. I couldn't think of any other way to word it... ONLY reason
If quality assurance work does not occur as part of the development work in Sprint, which benefits are lost? http://en.wikipedia.org/wiki/Quality_assurance
That was my understanding of quality assurance , so not transparent, not potentially shippable and probably technical debt
5 I thought the question was when should the team deliver the document... answer choices only left you with when it was part of dod
6 I'd say yes but judging by our company...not even that
That was my interpretation of it anyways
It is an odd questions , but the answer is obviously yes, because what is going into the sprint backlog is coming out of the product backlog, if the product log is ordered in terms of business value , and now the client's perception of value is seeing a document / API doc of how they can integrate the software , the sprint goal is to have the sprint deliver a DoD in line with the Sprint Goal , i'm sure that more often it'll be a working piece of software, but business value - keeping the client engaged - and collaboration for inspection and possibly adaption must take preference.
In theory, the purpose of a sprint is to create a shippable, working piece of software ... but if the value items at the top of the backlog are documentation, the client wants a walk through API doc to integrate , it could form of a late stage sprint item where user acceptance is being done, in scrum the typical software development artifacts don't disappear , not every piece of software will be a stand alone item. So if your sprint goal is a ATP and UAT , that will provide inputs into any future refinements ...
Until the product is discontinued, the Product Backlog never ceases, there will not always be development going on - if the client has limited resources to do UAT , it would make more sense for the PO to collaborate with the client once they have a set of UAT elements they'd like changed in final sprint changes.
the SDLC is still contained within Scrum, and scrum is ultimately a container ... release planning is another portion to be managed within the empirical steps provided for within scrum ...