Sprint Planning input/output

Sprint planning is done to achieve / deliver a product vision while going along product roadmap.

At least one needs to know what we need to achieve, why we are going through this sprint cadence, how we are going to achieve product vision.

Product backlog is must for sprint planning, yes for very new product we can refine backlog items gradually , as it takes time, and in due course of time we can achieve a good product backlog health and sprint backlog health.

After sprint planning, yes we have a sprint goal and sprint backlog as output.

Mandatory artefacts and other things-

Artefact - product backlog, backed by strong product vision and clear product roadmap, Financer/ Investor

Other things- infrastructure/architecture of s/w identified or available for s/w development, environment, resources, expertise (technical, business),  Dev team members , all stakeholders presence , meeting room or virtual meetup setting, understanding of sprint planning - why we are doing it - by all attendees , facilitatator for facilitating event

Can anyone suggest me please what is the mandatory artifacts and other "things" to start Sprint Planning and to finish the Sprint Planning?

You'll need a Product Goal to aim for, and a Product Backlog with items ordered and ready for discussion. Also an understanding of the Developers' capacity, so they know how much work they ought to take on, and a Definition of Done which describes the quality they must plan to achieve.

If there have been previous Sprints you'd expect at least one actionable improvement from a prior Sprint Retrospective. You'll also need access to the product so any planned value can in fact be added to it.

None of these inputs are mandatory. We want to start Sprinting now: that's the imperative. If any required inputs are unavailable consider workshopping them out on the spot. In Scrum there is no excuse for putting the establishment of empirical process control in delay.

The only artifacts in Scrum are the Product Backlog, the Sprint Backlog, and the Increment. Of these, the only one that is mandatory going into the Sprint Planning is the Product Backlog. You will be creating the Sprint Backlog at Sprint Planning and you won't have an Increment until sometime during the first Sprint. After the first Sprint, then being able to inspect the most recent product Increment and its place in the broader context could be useful at Sprint Planning.

The Product Backlog consists of the Product Goal and a set of Product Backlog Items. The real question is about the state of the Product Backlog going into Sprint Planning and how the quality of both the Product Goal and Product Backlog Items affects the team's ability to have an effective Sprint Planning session.

The Product Goal is created by the Product Owner. There's little mention of the quality of the Product Goal, but the Scrum Master does support the Product Owner in finding ways to effectively define the Product Goal in a way that is good for all of the involved stakeholders. If the Product Goal is unclear to the Scrum Team and doesn't help the team to craft Sprint Goals that serve as steps toward achieving that Product Goal, than it should be revised to help the team craft a Sprint Goal that defines the value for the Sprint at their Sprint Planning.

The Product Backlog Items go through a refinement process. The Scrum framework doesn't have a lot to say about what it means for a Product Backlog Item to be well refined and ready for a Sprint. The only guidance in the Scrum Guide is that a Product Backlog Item is "ready for selection in a Sprint Planning item" when the Scrum Team believes that it can be accomplished within one Sprint. In my experience, though, teams tend to think about a "Definition of Ready" that helps them understand what information is necessary to have confidence that the work is understood well enough to make the risk of taking it on acceptable.

A good amount of Product Backlog Items should be considered ready going into the Sprint Planning session. A common rule-of-thumb is 2-3 Sprints worth of Product Backlog Items should be well-refined and ready, based on how you count them. Some teams may use point estimation and velocity, others may use hours, others may use counts of Product Backlog Items. The exact method doesn't matter, but this gives the team the ability to shuffle the top of the Product Backlog based on feedback of the Sprint Planning and have a high likelihood of having well-refined items at the top.

It may not be possible to have the whole top of the Product Backlog refined going into Sprint Planning, though. Depending on the outcomes of the previous Sprint Review and Sprint Retrospective, the status of the top of the Product Backlog may change. The Sprint Review may shake up the Product Goal and/or the Product Backlog based on stakeholder feedback on the product along with changes to the product's context. The Sprint Retrospective may adjust the team's way of working, including the Definition of Done, that impacts how much work the team believes is achievable during a Sprint. Because of these changes, some refinement may be necessary at Sprint Planning or some work may be brought into a Sprint by accepting the risk of bringing in unrefined and unready Product Backlog Items.

there is no input (even if you don't have items to take to the SB you need to refine it at event)

If the work is that adhoc, why there is need for sprint and effort for sprint planning ? You can 'pull' the items into your daily board whenever it is deemed to be important and ready. But still from where you will 'pull' items ? You atleast need a backlog lean enough.

If any of the guidelines seems to be not fit for your product development, better not to use it rather customising the framework. The framework is kept open to experiment various practices and techniques within, not to experiment the framework itself ;)

Thanks to all and especially to Thomas. Very valuable information. 

I am a new in Scrum and want to ask: what are the outputs of the Sprin Planning? Sprint Backlog and Sprint Goal. Am i right?

The Sprint Backlog including the Sprint Goal. It also includes a forecast of the Product Backlog items to be worked on, and enough of a technical plan for the Developers to get started.