SCRUM Open Assessment question: First Sprint

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.

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!

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.

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.

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.

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.

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.  :-)

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

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

@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.