[Recently, an internal company thread discussed the “value” of user stories. In an agile context, what is the value of switching from a system of ‘tickets’ (someone writes a brief statement describing the work and the engineer goes off and builds a thing) to user story-driven development. Here are my thoughts.]

No matter what anyone says, value in a business context should ultimately be measured in $$ (ROI). If user stories don’t get you to ROI sooner, via faster time-to-market or with a better product, then they aren’t useful. And if we don’t know how to get that ROI faster, then just adding user stories to the process isn’t going to help.

If you want specifics, I could tell you about a project where User Story Mapping helped us throw away 2/3rd of the initial project scope - but the client still popped champagne on go-live. How? We identified that most of the requested features were like-to-haves used by a small percentage of their customer base, and we were able to shelve those. The 80/20 rule applies - and user stories should help you identify the 20% you should focus on first.

So: to me, the key part is the “user”. Well-written user stories allow us to deliver higher ROI faster because they help us decide which users and which needs we want to prioritize above all. Looking at a backlog of features, we should be able to quickly answer:

  • Which of our users needs this feature?
  • How much value is it to them (and, by extension, to our bottom line)? And how can we deliver that value in the shortest time?
  • How important are these users’ needs relative to all the others we could be serving?
  • What happens if these users’ needs are in contradiction with others’? Who wins?