Sprint Goal and Sprint success

Might the achievement of outcomes indicate success?

What I believed is if the team completed all PBI then I can declare the sprint as a success

I warn you that by using that as a measure of success can lead to the Development Team focusing on completing all of the items in the Sprint Backlog regardless of whether they are doing work that is quality and actually addresses the intention of the problem statement. 

What is the typical practice?

As Ian says, measure success by the achievement of the outcome.  I will add that my definition of outcome in this context is the intended increment of value that is quality and potentially releasable.  A successful Sprint is one that creates a potentially releasable increment of value that satisfy the needs of the stakeholder as determined during the previous refinement and Sprint Review.

Should the Sprint Goal be set first and then the forecast ?

How do you forecast work if you do not know why you are doing the work?  The Sprint Goal provides that guidance in determining which Product Backlog Items should be included in the Sprint Backlog. 

What if a Product Owner can't release every sprint or that sprint.  How can I measure the achievement of outcomes and give the needed feedback to the Dev-Team. 



I would consider the sum of the value points or business value but I feel that is not enough. 

What I believed is if the team completed all PBI then I can declare the sprint as a success. What is the typical practice?  

It may be considered a success for some people, but at the cost of reduced quality. Do you think such an outcome/product would really be valuable to the customer/end-user? 

The article also implies the development team having to work overtime and as a result lowering quality. It also mentions how stakeholders are "too busy" to inspect the Increment. Do you reckon these things support empiricism or the long term sustainability?

What if a Product Owner can't release every sprint or that sprint.  How can I measure the achievement of outcomes and give the needed feedback to the Dev-Team. 

Even though a Product Owner may choose not to release every Sprint, how else can we get feedback regarding the Increment? If releasing to the customer/public is the only way to get feedback, then perhaps its a topic for conversation with leadership.

What I believed is if the team completed all PBI then I can declare the sprint as a success. 

What if a Product Owner can't release every sprint or that sprint.  How can I measure the achievement of outcomes and give the needed feedback to the Dev-Team. 

Laith, what is your role in Scrum?   Responsibilities around declaring a sprint as a success, measuring outcomes, and providing feedback to the Dev Team are all Product Owner responsibilities.   Unsure if you are in that role, or working as a Scrum Master, based on your posts in this thread.

That said, there are strategies to elicit feedback on product increments that don't involve an actual release of the increment.   The Sprint Review is one event that supports such feedback.   Identifying a "pilot" group of users and/or stakeholders to use a product in a non-prod setting and provide feedback is another option.

Timothy, I will get soon a role as a Product Owner.

The philosophy of scrum that I get from you is that every sprint is a project which the scurm team can deliver an increment to the customer or a value to the product and the goal that the scrum team sets is based on that. If the scrum team manages to achieve an outcome that the Product Owner values then he/she can declare it as sucess regardless if all tasks were done or not. 



What a Product Owner could aim to get feedback, He could involve users, stakeholders and maybe technical experts in sprint reviews.  

Furthermore, like Timothy  suggest to use the product in a non-prod setting and let the users use it.

And most importantly a constructive and valid feedback from the stakeholder when the increment has been released which is an core indicator for the measurement of the the achievement of outcomes.



 

Good one Laith! Remember  the product owner is the entrepreneur of the team!