System stories for agile architecture [closed]

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)

Thermistor

Answer 1

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.

Lonnielonny

Delighting comment! Thank you! You really cleared my mind :). I had a search and found some interesting articles with definitions of tacchnical debts ( blogs.construx.com/blogs/stevemcc/archive/2007/11/01/… - codeartisan.blogspot.com/2008/08/… ). I think that keeping under control debts, mixed with a little design first approach may be the right choice for us. – Thermistor

Answer 2

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.

Subinfeudation

I believe this has more to do with a 'Sprint 0' approach, where you identify possible bottlenecks and technical challenges and put them under testing before you actually start development. This wont zero the risk but will minimize it considerably. – Tapis

Answer 3

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.

Tapis

Answer 4

In our team we call it "IT-cards", which is cards of the form: "As a developer. I wan't to refactor the xyz-component. To reduce maintenance cost and increase flexibility."

Team members are free to pick any IT-card they deem important instead of popping a "Feature-card" from the prioritized backlog.

I find this approach to work reasonably well to keep technical debt at an acceptable level and allow a healthy pace of innovation.

I've found it somewhat lacking as a means of re-architecting the system though. It's hard to justify to long departures from the feature producing flow.

As I'm writing this I'm thinking that one could approach architecture by theming the stories. Identify the architectual goals with epics that you break down into a theme to focus on.

Rodman

Answer 5

One lens that I find useful to take on developer stories is to think about who "the user" for any given story is. Just because you're not writing a feature that will be seen by people outside your company doesn't mean that there isn't a user for that piece of work. You may be writing code for a team down the hall. In some cases, the user is yourself. This is often the case for developer stories. Think "As a developer, I have a scalable architecture so that I can easily add new functionality." By calling out the particular user, it gives the product owner some insight into who will see the value of the story. And pointing out the "why" is also helpful to convey what benefit the story hopes to achieve. As others have mentioned, the management of the backlog does come down to a negotiation between the product owner and the team. And as always, you need to work out what works best for your team, regardless of process dogma. Every team has a different situation, and ideas that work well for one team don't always translate to another.

Eulogium