Skip to main content

SCRUM Open Assessment question: First Sprint

Last post 02:10 pm December 31, 2023 by Eric Naiburg
10 replies
01:30 pm December 20, 2017

Hello everyone. This is my first post. I want to apologize if I'm violating some rule, but I want to discuss about a question I found in PSM I open assessment that makes me doubt if it's correct:

+ Which two (2) things does the Development Team do during the first Sprint?



A) Deliver an increment of releasable software.

B) Determine the complete architecture and infrastructure for the product.

Correct answer

C) Develop and deliver at least one piece of functionality.

 D) Develop a plan for the rest of the release.

E) Create the complete Product Backlog to be developed in subsequent Sprints



I already know what the correct answers are since I failed in that question.

What doesn't have sense for me is, how can you deliver something in the first Sprint? Let's assume there's no previous work done and we are starting with product development and starting SCRUM adoption. We have our first Sprint. What wanna we deliver during the first Sprint or what we can develop for this first Sprint?



In my opinion, nothing, but I want to know about your points of view. Thanks in advance.


06:46 pm December 20, 2017

Hi Oscar, This is actually a great call out and I hope others will see this. This is a perfect example where the exams get tricky with wording. The Dev Team delivers the increment to the PO; not to the user/customer. I think this is where your confusion lies. Also, "releasable" does not mean it has to be released.

Think about splitting up the process of building a house into sprints:

Sprint 1: Foundation

Sprint 2: Framing

Sprint 3: Electrical and plumbing 

Sprint 4: Drywall

Sprint 5: Cabinets, appliances, etc

Sprint 6: Painting

At the end of the first sprint the house is nowhere near ready for move-in (release) but the construction crew (Dev Team) delivered the foundation (Increment) to the Architect (PO). The foundation is considered "releasable" because it is done and requires no more additional work between the end of Sprint 1 and the final release after Sprint 6.

For software, Sprint 1 can vary by product but it could be the databases necessary to be written for the product or other foundational pieces of the product, just as a couple examples. In many cases, a full product is divided among multiple sprints but releases only happen a small number of times. For example, a product that is spread over 12 sprints, could have 3 releases that will be after sprints 4, 8, and 12. In most cases, there is not a release after every sprint; if there is that's usually as the product nears full completion.

I hope this helps.


07:03 pm December 20, 2017

Curtis, I'm not sure about your suggestion for the first sprint.   While splitting by architectural boundary may work in some cases, I would highly advise against something like database work as a first sprint deliverable.   

As a preferred practice of mine, I advise my teams that most (if not all) PBI's should be somehow customer-facing.   That way, the deliverable can be seen, feedback received, and we're on our way working in an empirical fashion.

Perhaps the project is delivering a system composed of a number of screens.   A first sprint may then consist of building one or more fields on one screen.   Depending on what can be done in the sprint, a Development Team could include validation or business rules on the field(s), or leave them for a future item/sprint.

What is critical is that, as the team gets started figuring out how they want to build what they're being asked to build, they also begin building it!


07:17 pm December 20, 2017

Timothy, it was a random example and not a suggestion to be applied as general practice. For the products that my company does, databases are the first step and in the past we have found that if the database is not properly created; it causes the entire product to crumble. Therefore, we have chosen to have Sprint 1 be database creation for most of the products that we create. It works well for us, it doesn't mean it would work well for others.


07:31 pm December 20, 2017

Just another reminder: Scrum is framework which is applied to a vast number of products; not only software. For one product, laying the foundation is necessary for the first sprint but that design formula will absolutely not work for others. That is why it is a framework that can be used in countless different fashions. As an example Timothy, you suggested building a field on a screen in sprint 1. I would advise against that depending on the product; especially a product like what my company does because creating a field would be a waste of time without the database it needs. Again, it is dependent on the product; as I stated originally:

For software, Sprint 1 can vary by product but it could be the databases necessary to be written for the product or other foundational pieces of the product, just as a couple examples.

 


08:03 pm December 20, 2017

What doesn't have sense for me is, how can you deliver something in the first Sprint?

What is the smallest thing you can do to validate, with empirical evidence, that it is worthwhile to continue sprinting at all? There you will find your MVP. Examples might include an elementary market test of a business proposition, a proof of concept, or a usage scenario which validates an emerging architecture.

The releasable feature might seem very small compared to the overall work done in the first Sprint, and the potential users of it might be quite constrained, but the empirical data obtained from the increment ought to be useful and representative enough to validate key assumptions and to inspect and adapt progress.


04:41 pm December 23, 2017

A Sprint can be up to one month long, so use that full length if necessary.

If one month is not enough time to produce something with all the bells and whistles, produce something smaller/easier, without those bells and whistles.

Then it is possible to inspect which specific bells, whistles, or other functionality are wanted/needed next.

Even if it doesn't already do everything the customer wants, try to get their feedback early and frequently, and use it to shape the future direction of product development.

 


12:54 am May 22, 2018

New comment on an old post.

The Scrum Guide says "The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. "

A) Deliver an increment of releasable software.  

I think the key here might be that the answer specifically says software.  We need to produce a "potentially releasable "product" increment" - which is not specifically software.

C) Develop and deliver at least one piece of functionality.  

I think the confusion here might be the word "functionality."  I think the author of the question considers functionality and product increment to be synonymous.

Am I on the correct path here?

Also - is it time to freshen up the questions a bit.  :-)


03:50 pm November 18, 2021

That question is still in there (and still confusing). 


10:46 am December 31, 2023

It's 2023 now (tomorrow it will be 2024  haha) and that question is still there, and still confusing. I wonder if there's some official channel to follow to ask them to update the questions or elaborate further in the Feedback section on that question


02:10 pm December 31, 2023

@Aasiya, The question has changed and evolved over time since 2018, but is also still very important and relevant to a strong understanding of Scrum. If you don't think that you deliver some value and function each Sprint, then you are losing the focus on empiricism and the core of Scrum to deliver value. 

If you read the possible answers and the question in this test question there are only 2 clear answers because in the heart of Scrum is a Sprint, which is one month or less during which a done, usable, valuable product Increment is created. This applies to every Sprint.  Even the first Sprint, you should be able to deliver something to get you moving toward the Product Goal and to gain feedback on. 

Please note that this question is answered correctly 90% of the time, so although it may make you think it also is understood by most test takers.


 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.