Blending an Architecture Backlog over Feature Development

Salesforce.com, Amazon.com, Web.de, Yahoo.com and a lot of other companies that are doomed to fail if they do not continuously work on their architecture. These companies do have a big question:

How do you create an understanding how fast you build / re-do your architecture?

I do have a proposal to solve this question: 

  1. You might have an architecture team: An architecture board, team, system architecture teamjolegat-gloger-scrum-master
  2. They create their own backlog of functionality they would like to develop.
  3. Now they size every backlog item using a new unit: architecture points.
  4. This generates a number for the overall backlog
  5. Now they distribute their architecture stories to the feature teams. 
  6. The feature teams pick what they want to do and give these architecture stories Story Points based on their own opinions.
  7. At the end of the sprint the feature teams will have had developed the architecture story. This get reflected as such and such amount of architecture points is done.
  8. The architecture team counts all architecture points developed by the feature teams and add the architecture points they have build themselves. This gives you the overall architecture velocity of the company in architecture points.
  9. Now you can do what a product owner always does. He creates a release plan based on the backlog size and the velocity of the team(s).

Try it!

2 responses to “Blending an Architecture Backlog over Feature Development

  1. When there are two backlogs managed by different parties and the feature teams choose, from which backlog they take items, how can the product owner create a release plan?

    It may be the case that the team picks only architecture stories all the time. Then the velocity in story points may suggest a earlier release than would be possible.

    Or missed I something?

    Stefan

  2. First – the architecture team has its backlog, it is their releaseplan I am talking about.
    second. The PO prioritize the backlog. So they have to take the stories from the top.
    third. you can give the team a certain percentage of the sprint capacity for architecture. This capacity is expressed as a percentage of their own velocity expressed in their StoryPoints.

    Puh it is hard to talk about this in this abstraction. I try to do a picture – and upload it — asap.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s