BrainsLink

Linking the left brain and the right brain

Stories: The 6th (and Final) Level in Building a User Story Roadmap

This is the seventh in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. The focus of this final post is the user stories.

If you’ve been following this series since the beginning, you already know how to write good user stories. The INVEST model coupled with the standard agile story format is all you need to get started. (Of course, you’ve defined the goals, stakeholders, needs, themes and epics, right?)

For those who joined this series late:

The INVEST model describes user stories as Independent, Negotiable, Valuable, Estimable, Small, and Testable.

The standard story format is “As a <role or persona>, I want to <accomplish something>, so that <benefit or reason>”.

I won’t bore you with a detailed explanation of how to write user stories. If you’re looking for a beginner’s guide start here. If you have questions, leave them in a comment to this post and I’ll try my best to answer.

Follow the User Story Roadmap

My objective in writing this series of posts has been to get you thinking about a disciplined and structured way to approach user stories. Diving into stories and rushing to implement some code doesn’t work for enterprise software projects. Leave that approach for quick software changes or simple software utilities.

Enterprise software demands a top-down approach as I’ve outlined in this series. The one exception to that guideline is the spike. What is a spike? A spike is a special type of user story. It’s an experiment and the resulting code is often thrown-away.

Spikes are a way for the team to try out an idea, test a hypothesis, or run an experiment. Spikes are a great way for teams to better understand a problem definition or a solution space. Spikes generally take a vertical slice through the target system. In other words, spikes cut across the software system rather than simply exercising an isolated portion of it.

So spikes don’t need a roadmap. Business solutions do.

The user story roadmap is now complete. We have covered Goals, Stakeholders, Needs, Themes, Epics and Stories. I hope this roadmap approach helps you build great software. The world needs more great software and lot less crapware!

photo credit: The hills are alive via photopin cc

Updated: September 23, 2012 — 9:42 pm
© Damicon 2014 Frontier Theme