Velocity Labs
Gathering Requirements Through Story Workshops
Traditional requirements gathering can take an enormous amount of time, keeping developers occupied for long periods documenting the requirements instead of writing code. Sometimes this produces hundreds of written pages of documentation that can become obsolete once the first line of code is written.
At Velocity Labs, we believe that working software is more important that a mountain of documentation. We understand that requirements change and we're flexible enough to handle those changes, whenever they may come. We're big proponents of the Agile Methodology and one of the principles of agile software development states:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
The Story Workshop
In order to not spend time and money unnecessarily on a heavy requirements gathering process, we use a technique called a Story Workshop. It is a technique for eliciting roles, functionality and values of the system from key stakeholders.
We try to limit the initial story workshop to no more than two hours and we gather every idea for functionality in the system, even if we know that it's not something we'll be doing any time soon. At this point, the stories are at a pretty high level; more details of the story will come later.
Anatomy of a Story
A story is kept simple and follows a pretty standard formula.
As a ROLE IN THE SYSTEM
I should be able to ACCOMPLISH SOMETHING
So that I GET SOME VALUE
Roles
Roles are all of the different types of actors in the system. These could be users, managers, administrators, system administrators or even the system itself.
Functionality
Simply put, this is what the system allows an actor to do. Examples of functionality might include authenticating, sending an email, inviting another user, uploading files or creating data in the system.
Values
This is where things get really interesting. By attempting to record the value that a certain piece of functionality brings to the system, we begin to understand the motivation of our clients and their intended users. What problems are they solving and how does it fit in with the rest of the functionality? This key piece of information is extremely useful when it comes to prioritizing the stories.
Estimating
After about two hours we usually have a long list of desired functionality, a list of roles in the system and a better understanding of the problem this product will be attempting to solve.
We take these stories, estimate the effort we believe it would take to implement the functionality and arrive at an estimated time and cost for the product. We use the term estimate continuously here because we know that the requirements will inevitably change, and as the requirements change so do the time and cost of completion.
Summary
We find that the story workshop process can often be a cathartic experience for our clients. Not only have they captured all of their ideas regarding the functionality and roles in the system, but they have also had to think critically about why those things are important, or if they even are.
It's a challenging two hours for our development team and our clients, but in the end, it is an essential part of how we build great software.
Need help with your project?
We specialize in Ruby on Rails and JavaScript projects. Code audits, maintenance and feature development on existing apps, or new application development. We've got you covered.