Storie not finished

Which of the options you describe would allow the team to deliver useful work of release quality each and every Sprint?

If none of them do, what would it take to actually overcome the integration constraints you describe? Is there an organizational appetite to release work every Sprint, to inspect and adapt based on such evidence, and to thereby obtain the benefits of Scrum?

I am reading the answer by Ian and I can't understand it. What is "organizational apetite" ? How could we overcome described constraints ? In described situation it seems not possible to deliver finished piece in one sprint.

In my team we have not finished piece for two months already. No one really knows when it will be finished. I have found out that it is not scrum which we are using. We are using some agile variant. I have some recommended reading about our methodology. 

What is main purpose of sprint? Deliver potentially shippable product increment of "Done" product at the end of each Sprint. Are you sure that you can not split PBI in a way that working part of it could be delivered in one sprint duration?



Avoid concepts like pushing unfinished work to the next sprint, there should be a space for PO to reprioritize "returning" PBI and there is a chance that priority will change and it could not be part of next sprint backlog.



Do what is right, not what is easy

Are you sure that you can not split PBI in a way that working part of it could be delivered in one sprint duration?

This is a very good point. I've noticed that when teams think they can't split a PBI, they often can, but don't think it can provide value.

Mike Cohn has a couple of blog posts on this topic, one of this is this one:

https://www.mountaingoatsoftware.com/blog/five-story-splitting-mistakes…

There are problems which cannot be solved in 10 sprints or problems for which we don't know whether solution exist. For example: " develop component X in better way".

Marek, those are very vague points you're making.   What is "better" by your definition?   Is "better" different with others in your organization?

Problems that have a high degree of uncertainty can benefit from either a spike to investigate potential paths towards a solution, or from small experiments that either validate or invalidate potential paths.

Think of your "problem" like Edison inventing the light bulb.   He didn't just set out with a goal to create a light bulb and gave up when his first attempt failed.   He iterated, process learning and feedback, and improved his model until he achieved success.   He is known for quoting "I didn't fail 100 times trying to create the light bulb.   I learned 100 ways not to create a light bulb."

Treat your problems and uncertainties as opportunities for learning, and construct your iterations to support that learning-based feedback loop.

My point is to test what scrum is saying about work which cannot be completed within sprint for several reasons. One reason is that it is research kind of work for which we may define spike as you say. Second reason are expected and not expected obstacles met during development. We can discuss these obstacles and still do not know how to overcome. For me it is difficult to explain it here, because I am getting nervous. I need psychological help, because I am seeing other team members as impediments. I see managers as impediments as well - due to several constraints which they define.

By "better component X" I mean component which is already working but has some drawbacks: support cost too much, was developed with low quality, does not fit to other components, etc.

Marek,

I would highly recommend reading the section in the Scrum Guide titled "Sprint Planning".   Scrum mandates that the development team only forecast work that they believe they can complete within the sprint.   You should never set out in a sprint with an acknowledgement that items will not be completed within the sprint.

That said, there is an old adage in Agile: "Failure is not an option.   It is mandatory."

Do not be afraid of failure, or a sprint not playing out as expected.   What is critical is that, if there are issues that negatively affect the execution of a sprint, that the Scrum Team assesses the issue(s) during their Retrospective, and identifies ways to mitigate and/or avoid such issues going forward.

Failing one time is perfectly fine.   Failing twice around the same issue is a problem.

My workplace is currently adopting the scrum approach however the issue discussed here seems to surface for us also.

Lets assume that we are working according to the scrum process, with a brand new product and we're starting from zero. There is an element of learning for several members of the team and so estimations are wild due to the degree of unknowns. 

You reach a point where what the team is capable of delivering within a sprint is not in a release-able state, half their time spent setting up the project and getting in groundwork. At this point the product is doing nothing, it's not visibly 'functional', not ready for public consumption and even any API's are not fleshed out enough for public consumption.

The development team accepted this amount of work because its what was possible to deliver within the constraints of a sprint, however the product owner has nothing to view for the sprint.

How are you supposed to handle work that cannot qualify for release within a sprint? Breaking it down is not an option because you will end up with more work items to represent something which will still be no closer to release within the sprint.

Nobody say, that it is easy thing to do the shift in mindset to deliver small increments within a sprint duration that is in usable state for the end user. Maybe it will be only ability to create account without login part (?). Before you create highway, you have dirt road and sprint after the sprint, you bring to them more value, at first they can go one by one from A to B, then they can also return one by one from B to A, then they can go faster, then not only one by one but alongside on multiple lanes etc.

The key thing is to deliver a potentially releasable Increment of "Done" product at the end of each Sprint, and doing for example only frontend part of work is not delivering potentially releasable Increment.

It would be nice to deliver every increment to the end user, but whether or not to release it is up to POs decision. The increment must be in useable condition regardless of whether the Product Owner decides to release it.