Does architecture count as an increment?

Last post 02:10 pm April 26, 2022
by Berny Land
4 replies
Author
Messages
12:17 pm April 26, 2022

I have a team that splits their work into four stories: Specification, Architecture, Implementation and Testing.

They have a list of requirements and specify it in one sprint, do the architecture in another sprint and may do the implementation and testing in the third one.

The scrum guide says:

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.

So while they argue that architecture for example is additive to prior increments, I believe that it does not provide value since it is not usable.

They say they can't work any other way since there are restrictions.

 

So it kind of looks like this:

Sprint 12:

Architecture Story for Project A

Testing Story for Project B

Sprint 13:

Implementation Story for Project A

Technical Debt Story

Sprint 14:

Testing Ticket for Story A

 

I was about to offer my thoughts on the matter but got shut down pretty quickly, saying it does not work any other way and those stories are in fact concrete stepping stones towards the product.

Is my understanding of increments wrong? Does it make sense to have separate stories for one outcome?

12:46 pm April 26, 2022

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.

01:02 pm April 26, 2022

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?

 

01:39 pm April 26, 2022

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.

02:10 pm April 26, 2022

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?