Does architecture count as an increment?

Consider two statements from the Scrum Guide:

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

and

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

By realizing the Sprint Goal, the Increment is not only a stepping stone toward the Product Goal, but a way to deliver value to the customers and users of the product, and only usable products are valuable.

Are you producing a usable Increment each Sprint? It's quite conceivable that a particular Product Backlog Item may take a couple of Sprints to go from an idea through refinement, then be selected for implementation, and finally delivered. However, if you are forcing this kind of life cycle into the Sprint timeboxes, then perhaps you really have a sequential (or waterfall) process masquerading as an iterative and incremental, or agile, model like Scrum.

Are you producing a usable Increment each Sprint?

There is no focus on this as far as I can tell. We at least try to do the four tickets in one sprint but it's possible that there are sprints like example sprint 13 where there the item is implemented but not tested and the rest of the tickets are equally "unfinished". Most of the time rest of the stories slip into the next sprints.

Would it be in the sense of scrum and agile if we had, let's say, 5 tickets, 4 of which are are architecture stories and the fifth one being the testing ticket, thus creating a tested and finished increment with this fifth one?

So basically as long as we have at least ONE item at the end of that is finished from specification to testing it's fine?

To have a real Sprint a team must go into Sprint Planning, every time, with the genuine, serious, Honest-to-God intention of providing at least one usable increment no later than the end of it. That's the only way empirical process control will be established and maintained. It's also what we mean when we say an increment must be Done and potentially releasable.

It's amazing how inventive organizations can be at breaking this very simple thing called Scrum, and of course the pressure is on you to change what Scrum means, rather than have everyone go through the pain of organizational change. It's important to question whether outcomes will really be any different under these circumstances, and also to know where any sponsorship for genuine change lies.

Ok, so suppose we do this and make that one story in the sprint that's left to complete all four our goal, because that is what we need to do to have an increment in this sprint. That would do the trick, wouldn't it?

Another question that goes along with that, since in that case it is okay to have those waterfallstories and each one has different done criteria: How do we best define the DoD?

Is it okay if it's looks splitted like this (not complete, just as an example):

Architecture

-was documented

Implementation

-code has been pushed

Testing

-all requirements are tested

 

Or should the DoD be consistent for every PBI?