Analysis as a task in Sprint? putting unanalysed asignmeents/bugs in sprint?

Items which have not been sufficiently refined ought to remain in the Product Backlog.

In your situation, how was "issue X" estimated and made ready for Sprint Planning? 

There is something called Spike in Scrum. If you are using JIRA tool for project mgmt then you can raise a spike for things which yet be analyzed by team.

If you are using JIRA tool for project mgmt then you can raise a spike for things which yet be analyzed by team.

A spike is a time-boxed initiative to learn something that can determine future direction/priority.

As Scrum Masters, we should caution teams against creating separate "spike" items that only serve as the analysis portion of another PBI.

Well, there are some points to clarify.

First, bugs caused by development of pbi, are expected by the the development team. Second, if the team find a problem that cause risk to the sprint, so the team must talk to the product owner and decid if the effort will affect the sprint goal. If so, the product owner have to decid if the sprint will be canceled. Third, no requests can be made after sprint planning, even by product owner, cause this could put the sprint goal in risk.

Depending on what the analysis entails exactly, it could be considered a part of the workflow of an item in the Sprint Backlog.

However, if the Development Team cannot provide sufficiently accurate estimates and forecasts, or is inhibited in its setting of Sprint Goals, it probably suggests the need for better refinement.

Third, no requests can be made after sprint planning, even by product owner, cause this could put the sprint goal in risk.

I disagree. The Product Owner is free to make requests at any time. Of course, if the Product Owner embraces the Scrum Values, he or she would be respectful of the Development Team's need to focus, and would limit such requests to when there is a good reason.

It is the duty of the Development Team not to make decisions that would put the Sprint Goal at risk. So they should decline such a request if it is a distraction, or perhaps even competes with the goal. A healthy Scrum Team will collaborate to find the best way forward, which could involve changing the planned approach towards achieving the Sprint Goal.

The Product Owner retains the right to cancel the Sprint if the Sprint Goal has become obsolete, and focus should be shifted elsewhere.

would you put an analysis as a task in some sprint? Or bug/request that would require analysis? i have situation that in sprint we are putting task "analysis of issue x" or some bug resolution that would require whole cycle (analysis, design, implementation..). My feeling is that not analyzed things should not be put in sprint, but kept in sprint backlog, but i would like to hear your opinion.

The way it's actually supposed to work is as follows: the team meets (timeboxed) and discusses (sprint planning) what can be realistically achieved during the iteration considering business-PO's priorities and DT's confidence of starting and completing a certain amount of work - sprint goal is crafted. If, post sprint planning, changes are wanted, there are several scenarios to consider:

• story requests made by anyone else outside the scrum team should be politely declined, and SM & PO involved.
• PO's story requests can be negotiated with the DT, with a common understanding the sprint goal may be adapted
• critical bugs/defects should, in my view, always be considered for inclusion - but then again, there's a risk the goal would be impacted; this bug chart can serve as a starting point for the team
• DT is always free to adapt the sprint backlog, as they see fit - that is, as they learn more, they realize more.
• analysis (I guess you refer to a spike) should normally be avoided, but if absolutely necessary for the team, it must be selected during sprint planning - and the majority (myself included) is of opinion spikes should be estimated in hours (rather than storypoints) and the timebox must be enforceable.
• stories not refined and estimated should not be selected for development - and, in fact, not even discussed during sprint planning, except in very limited cases where the stories have recently been put at the top of the backlog and the team must work their way towards grooming and estimating, with a view to select for sprint coverage (if they are of a certain size that the dev team's confident they can complete in said sprint)

I fail to understand the rationale behind this statement "bug resolution that would require whole cycle (analysis, design, implementation..)" The "cycle" you refer to may be applied to stories. Bugs need one thing only: investigation. For this reason, most practitioners recommend not to estimate most bugs. So whenever there is a bug reported, depending on severity, the team would look into it (surely, not all of them at once, but they'd decide how to approach). In fixing bugs, there is no analysis, no design, no "implementation". Just investigation - then an appropriate fix. Sometimes the fix can be as easy as adding or removing a character, or much harder (rewrite a few hundreds code lines due to an API clash).

We have a product backlog which I review and update as the BA/PO.  New items are prioritized, and then I work on them in the Backlog to get them as clear as possible prior to the grooming session.  During the grooming session, the developers review the stories with me and if they are satisfied that they know what they need to know to get started, the backlog item is moved to an Approved status, which means it's available to be brought into a sprint.



During Sprint Planning, we review all of the unfinished work from the previous sprint and then look at approved work that is ready to be worked from the Product Backlog. 

So far it's working pretty well.  I am usually at least 2 sprints ahead most of the time as far as having stories detailed out with the business, and at the point that we review the approved stories, we're able to know we are ready to to go.