An Agile Experience: My First User Stories

Managing requirements and project planning via a shared concept of user stories is the crux of agile development, at least from my current BA viewpoint.  Over the past few weeks I’ve had the chance to “write” user stories and even see a few of them implemented and tested.  Overall, it’s been a positive experience.

First off, we are working as a lightly geographically dispersed team.  The “business” side is about a 5 mile drive from the the “technology” side.  I call this project team trait out specifically because I decided to store detailed functional requirements in the user stories.  What I am writing on each story might fit on a single page, but it would never fit on an index card (the traditional “size” of a user story).  We have active communication but not daily communication.  Moreover, the business has historically documented very detailed requirements and maintains a repository of use cases and supplemental specifications that has been kept fanatically up-to-date since the system was launched 7 years ago.  I can conceptually see the index card approach working in a highly communicative, co-located environment, but not for this project.

So, I ended up with a lot of detail in my user stories.  Essentially, they are both buildable and testable.  There are details about every field on the page, every exception, and notes about how we see this page extending in future iterations.  Early on, I found myself writing mini-use cases and in many ways these stories are still very compartmentalized use cases. Coupled with the user stories are a set of click-through wireframes that represent the overall flow of the application.  The wireframes are used to confirm requirements across a broad set of business stakeholders.

A key challenge for me in breaking apart the system into these very small components has been keeping an eye on and communicating the big picture. Whereas in my prior experience a use cases revealed a piece of functionality end-to-end, this set of functionality might break up into 3 or more user stories. The wireframes definitely help as at least there is a big-picture visual, but they lack the logic of a use case.  I’m experimenting with some diagramming methods and started diagramming the flow between stories for a specific iteration.  I think something along these lines might emerge as a best practice for me.

A key positive in this experience has been seeing a very small development team with minimal capacity deliver something that works and fulfills on requirements, albeit a very small component of an overall system.  In my old use case world we’d have nothing to check off the list.  In the new agile world, we checked 5 things off the list. I am starting to experience a bit of that agile utopia where you get into a rhythm of delivery.  As one of my best mentors always says, the way to eat an elephant is one bit at a time.  I’m seeing agile provide a framework for ushering a team through such a large feast.

Comments? Suggestions?  I’d love to hear them.  Chat away below.

Like hearing about new agile experiences? Then you might also like my post on “My First Product Backlog“.

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

1. Defining the scope of an epic before listing user stories in an agile product backlog
2. An Agile Experience: My first product backlog
3. Grooming the product backlog: agile requirements management for improved sprint planning