SCRUM Open Assessment question: First Sprint

Last post 07:54 pm November 18, 2021
by Katinka Hesselink
8 replies
Author
Messages
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).