I struggle with how to account for infrastructure and technical user stories. These stories invest in a product’s longevity and infrastructure. Many people struggle with how to grapple with inwardly focused stories saying that they are not true user stories.

In light of this, what is the correct way to handle this? Do we stop improving our internal processes (e.g. building, certification, deployment, etc.)? Do we stop decoupling our code or implementing best practices? Absolutely not! These stories deserve their own investment.

Liz Keogh provides an excellent road map in her article titled They’re not User Stories, where she introduces a much more fitting title of “stakeholder stories”. Their value differs from typical user stories, but  they position the product to complete future externally focused user stories.

Advertisements

One thought on “Technical/Infrastructure User Stories

  1. Thanks! It might be worth considering other stories too which aren’t even for the benefit of the user – adverts, CAPTCHAs, security, architecture, etc. There’s a business benefit to all of them, and some of them will create differences in user interaction, but there’s no situation in which a user *wants* to fill in a CAPTCHA box. I’ve found recognising this can really help us to talk to the right stakeholders and make sure that user experiences are as pleasant as possible given the constraints.

    Like

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