Committing On A Sprint Goal


Recently my team had a discussion about completing  User Stories that are not part of the Sprint Goal. The statement was:

User Stories that the Developers forecasted but are not part of the Sprint Goal don’t have to be DONE by the end of the sprint.

Is that right? Does the development team only commit to the Sprint Goal? Or does it commit to the accepted requirements? (If it commits at all and doesn’t just forecast)

Which brings me to a couple more questions:

Is it correct to have a Sprint Goal that does not cover all User Stories in the Sprint Backlog? What’s the purpose of the Sprint Goal?

Quoting form the 2011 Scrum Guide:

The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within a Sprint. […] In order to satisfy the Sprint Goal, it implements the functionality and technology.

What kind of flexibility are we talking about here? From my understanding, the goal will automatically be reached by completing all of the requirements the Developers forecasted, no matter what the Sprint Goal specifically stated. Therefore the Sprint Goal shouldn’t have any relevancy in the Sprint Review. Correct?

So  it should be in the best interest of the Product Owner to have the Developers work on requirements they can get DONE by the end of the Sprint. At the end of the day it comes down to potentially shippable working software. That’s how we measure progress in Scrum.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s