System stories for agile architecture

Question

While trying to apply agile principles to our development process, in particular scrum principles and XP-like user stories, we faced a problem about the architecture.

Maybe we are still too much linked to the architecture-centric development, however we are trying to maintain a strong component based development, mixed with the agile modeling principles. Our aim is to have a small design up front, prone to evolutions during the development.

What I'm looking for is something that could let me place into my backlog stories about my architecture and the components inside of it: development stories, not only usage stories. System story could be a different kind of user story, which tells something that is not strictly related to business value, but that is instead linked to architecture and quality concerns of a system.

Edit: I found this research of the Aalborg University about "developer stories".

Have you any experience, idea or opposition?

Thank you in advance! (this is my first question! :D)

Answer 1

My answer here applies.

There is a very challenging balance between doing architecture work and more feature specific work. Technically both are valid approaches and work, but the longer you delay some amount of usable product (sprint results) the larger the risk you take that you aren't building the right product (user requirements, performance requirements, ect.). As early as you can, get to a point where you can perform system level tests to prove your product works and you can demonstrate the value and direction of the product with your stake holders.

Answer 2

It is as simple as putting a Make sure the Membership component can be tested unplugged from all the other components 'user' story, your backlog SHOULD have system/development-stories, as long as it is sync'ed with the product owner's desire of such implementation.

This is how we usually put the non-functional requirements in a backlog, like "The domain model has to run on a different datacenter under load balancing" etc.

Answer 3

IMO a backlog should not include developer stories. There is no way that any Product Owner can sensibly prioritise these alongside business functionality. And what happens if the Product Owner deems one of them unimportant and so pulls it out the backlog? If the team then insists on keeping the story, you are in a situation where ownership of the backlog becomes unclear.

However, I do definitely think that the team need to build architecture early on in the project. One problem on my project was that we focussed too heavily on functionality in the first few sprints.

Let's think about "architectural debt" (similar to technical debt) as time that needs to be spent building infrastructure and architecture. Unlike technical debt (which starts at zero and builds up as the team produces functionality without proper refactoring), a team starts with architectural debt and must work to reduce it. Time spent reducing architectural debt means that less time is spent producing functionality, i.e. a lower team velocity and reduced sprint output. In this way architectural debt is similar to technical debt. If requirements emerged that didn't fit the current architecture, then the level of architectural debt would increase.

Bear in mind, that the team should decide (and be able to justify to the Product Owner) how they are going to spend their time. And so they can split their effort between functionality, technical debt and architectural debt as they see fit.

Architecture work should still be driven by functionality though. In other words, the team should build infrastructure to support and enable a particular user story. Not just because they think it will be useful in the future. The YAGNI principle applies to that sort of approach.