can this be sprint goal?

The sprint goal is usually aligned with the product goal, as the sprint is supposed to bring more value to the product with each increment. 

A usable and potentially releasable increment is an increment that includes at least one PBI that meets the scrum teams definition of done. 

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

• Let your developers get creative. They know best how to get work done to achieve the goal

• Do not close yourself to tasks, give the opportunity to be flexible

• One goal will strengthen the team's focus on achieving the goal

Tasks, testing, creating a demo are just milestones. 

Consider the bigger picture. The sprint goal should bring you closer to the product goal

can this be sprint goal?

A User Story is a placeholder for a conversation about a potential requirement. How could a phase possibly be a good User Story, and how could the two confections you describe possibly lend coherence and focus to a multidisciplinary team?

Those sound like items that I would have on a Definition of Done not a Sprint Goal.  Sprint Goals indicate to the team what is the most important reason for executing the Sprint.  What value will be created by accomplishing items that are in the Sprint Backlog. They are usually a single statement that shows how the stories in your Sprint Backlog are related and come together to create some form of value.  

For example if Story 2592 is for creating the ability to filter a table by a country code and Story 2588 is to convert money values into different currency types, your Sprint Goal could be "Make it easier for customers to provide cost information to current/potential customers in forms that are applicable to the international market in which the customer is based."   You could also have a 3rd story that would reformat dates in the same fashion that you are converting currency.  

Thank you Pawel, Ian and Daniel . From your replies- I can conclude that- :

1. There should be just one goal and NOT multiple goals for any sprint

2. Goals I have mentioned above are just phases and do not qualify to be sprint goal

3. The sprint goal should bring you closer to the product goal

I will discuss these points with product owner tomorrow and will update this thread.

Vishal I agree with all aforementioned aspects,

just keep in mind the agile maturity of your team-organization .

We have seen many teams that are working under an hybrid scrum model and they cannot digest some agile stuff. 

Many times we create restrictions around scrum framework and the teams dont have the maturity  to harness the agile outcomes from it. We want to cultivate the agile culture and mindset to them .

SM and PO should share the product goal and the vision in order to keep people focus and aligned with company's strategy.

Sprint goal can be divided into smaller chunks into the sprint in order to be more comprehensible from the team members and definitely part of the product goal.

From my point, the agile readiness  of each team depends on the agile culture that they have reached, we need to help them to unleash their internal agility not to create predetermined agile models.

Sorry for the late reply. We encountered production bug and numerous other issues (not finding new developer etc etc) and finally will have my discussion with PO tomorrow on Sprint Goal topic with respect to suggestions given by each one of you. Ilias-I will surely keep agile maturity of team in mind. Thanks.

One more doubt here - :  

 We have quarterly production release. So, our client is Okay even if we don't add "Value" at the end of the sprint. What I mean is- if we don't complete Development + Testing at the end of the sprint, client is OKAY. We have liberty to complete testing in next sprint.

Now you may say - You should make sure development + testing gets completed in single sprint.

Agreed. and we are working towards it by replacing Virtual Desktops(VD) with cloud based VDs (so that team members won't face VD issues and they won't loose their precious time), replacing non-performing team members etc etc.. So, in next 2 months we can expect improvement no doubt.

But- what I am mentioning here is the condition as of today.

So, in present scenario - will it be rational to have a Sprint Goal like the one Daniel mentioned?

Make it easier for customers to provide cost information to current/potential customers in forms that are applicable to the international market in which the customer is based

To make it more easy for you to understand- : Let's say we are actually working on above Sprint Goal . Let's assume. But - :

(a) We are not deploying at the end of the sprint- : So, we are not meeting Sprint Goal expectations of making it easier for customers to provide cost information.....etc etc 

(b) We are not completing testing in the same sprint.. Some part of testing gets completed in next sprint

In such case- What should be our sprint goal strategy ?

Hope, I am pretty much clear.

The whole point of Scrum is to create a Done increment. Without Done work there can be no Sprint because empiricism cannot be established. No Sprint means no Sprint Goal. Scrum is not a pick and choose framework.

There might well be goals of some kind which your team can agree and commit to, even if they are not Sprint Goals and Scrum is not yet being implemented. Whatever those goals are, they should give your team members a reason to work together as a team, and not to drift off pursuing separate initiatives.

(a) We are not deploying at the end of the sprint- : So, we are not meeting Sprint Goal expectations of making it easier for customers to provide cost information.....etc etc 

Too many people get hung up on the concept that if the changes aren't deployed to Production, the changes have no value.  That is not always true. Sometimes you might have to introduce some foundational work in order to be able to deliver to the customer.  Or you might have work that could be deployed but choose not to do so because the work by itself does not warrant the interruption of the users.  

The purpose of a Sprint is to incrementally deliver value that the stakeholders would find useful. That doesn't mean that every Sprint will deploy to Production.  The Sprint Review still allows the opportunity to get feedback and adapt accordingly even if the work is not in Production.  The Sprint Goal helps to define the value that you intend to have available in an increment of the product. 

In such case- What should be our sprint goal strategy ?

Your Sprint Goal strategy is most likely not the problem based on your description.  The problem is with the process that you do to accomplish the work.  If your team doesn't do all the work that they feel is necessary to deliver value, the team needs to have serious discussions about why that happens and what can be done to prevent it.  I understand that there could be times that it doesn't happen and that is not something the team should feel is a failure.  They should instead take it as an opportunity to learn.  If the team is constantly having the issue, then hard conversations need to take place that might not paint everything/everyone in the best light.  There is usually a reason why it happens. The root cause assessment isn't to place blame on anyone, it is to identify the real reason so that a solution can be implemented to improve.

In my opinion everything you have mentioned is a problem with the process and commitment of the team to deliver value.  There will not be a single fix for it all. I am not sure that you are focusing on the real problem and seem to want to consider it ok that the team is not commiting to accomplishing the bare minimum of completing all the necessary work within the Sprint. I know this will sound harsh but quit making excuses and start working on solutions.  And just because the client is ok with not completing the work in a Sprint boundary does not mean that a team with pride in the work they do should be ok with that situation.

Thanks Ian & Daniel.

Read your replies & noted.