rails product planning
Last updated 5 May 2013
This article from the RailsApps project suggests how entrepreneurs can plan software development for startups and personal projects. It describes product planning with “user stories” and introduces the concept of behavior-driven development as part of the software development process.
If you’re new to Rails, see What is Ruby? And Rails?, recommendations for a Rails tutorial, and a list of top resources for Ruby and Rails.
The RailsApps project provides example applications that developers use as starter apps. Hundreds of developers use the apps, report problems as they arise, and propose solutions. Rails changes frequently; each application is known to work and serves as your personal “reference implementation” so you can stay up to date. Each is accompanied by a tutorial so there is no mystery code. Maintenance and development of the RailsApps applications is supported by subscriptions to the RailsApps tutorials.
Some people think software development begins with writing code. But in fact, product planning is the first stage of the software development process. Product planning, which is at the heart of going from “concept to code,” is critical in getting a project off to a good start.
Arguably, for a simple application you build yourself, you don’t need a lot of “ceremony.” There’s no need for a written specification. Just write some code. But though your application may seem simple, if you’re a solo operator, product planning can be helpful. Software projects have a tendency to grow complex and take longer than planned. At a minimum, product planning will help you focus your ideas before you begin coding. If the application grows complex, it will help you track progress and stay on course.
For ambitious projects, when you are part of a team, or when other people’s time and money are at risk, product planning is a key element of a robust software development process. If you plan on growing a company, product planning is fundamental.
It’s up to you to decide how much time you will spend in product planning. But consider some of the benefits:
- It helps you discover the functionality you need to implement.
- It helps you describe and discuss features with your business partners.
- It serves as a “to-do list” to help you track progress.
- It is the basis for acceptance testing or integration testing.
A robust software development process will also include project management and testing. See an article on Rails and Project Management for more on project management.
If you are startup founder or building your own project, it’s obvious, you are in charge of defining what your application will do. But think for a moment about the more difficult role of a student who is given an assignment, a consultant who builds a client’s project, or a team in a corporate development environment. Someone has given you the task of building an application. Somewhere between the lofty goal of the project and the implementaton details lies a grey area of product features and requirements. Typically a client or executive management will not provide a fullly developed specification of product requirements. And many developers just want to know what to build. Into that void steps the the product owner.
The product owner can be a technologist or a business person. The responsibility is to look at the application from the point of view of the application user and decide what features and functionality are essential for the user and what must be left out. Without a product owner, a project can collapse in vagueness or drift by whim, ultimately satisfying no one.
A product owner’s principal tool for product planning is the user story.
User stories (definition: user stories) are a way to discuss and describe the requirements for a software application. The process of writing user stories will help you identify all the features that are needed for your application. Breaking down the application’s functionality into discrete user stories will help you organize your work and track progress toward completion.
User stories are often expressed in the following format:
As a <role> I want <goal> so that <benefit>
As an example, here are user stories for the rails-prelaunch-signup application from the RailsApps project.
*Request Invitation* As a visitor to the website I want to request an invitation so I can be notified when the site is launched *See Invitation Requests* As the owner of the site I want to view a list of visitors who have requested invitations so I can know if my offer is popular *Send Invitations* As the owner of the site I want to send invitations to visitors who have requested invitations so users can try the site *Collect Email Addresses* As the owner of the site I want to collect email addresses for a mailing list so I can send announcements before I launch the site *Social Network Sharing After Sign Up* As a user I want an option to post to a social network after I sign up so my followers will learn about the site
We can use this list of user stories as our task list in implementing the application. The article Rails and Project Management shows how you can track progress implementing user stories with a simple to-do list or more complex project management tools.
Behavior-driven development (BDD) is an effective methodology for software development that turns user stories into a test suite for acceptance testing or integration testing.
Here’s how user stories can be the basis for behavior-driven development using Cucumber:
- write user stories
- user stories become Cucumber scenarios
- create acceptance tests based on Cucumber scenarios
- code each feature
- run acceptance tests as each feature is completed
Cucumber scenarios turn user stories into plain-English descriptions of a series of steps to execute a product feature. Cucumber is appropriate when a team includes nonprogrammers who are involved in defining product requirements or there is a need for a specification and acceptance tests to be maintained independently of implementation (for example, when implementation is outsourced).
There are alternatives to Cucumber that may be more appropriate for smaller projects or teams of people who are comfortable reading software code.
Many Rails developers create integration tests using Capybara in combination with RSpec as described in Ryan Bates’s How I Test Railscast.
User stories can still be the basis of product planning using the RSpec and Capybara approach; instead of using Cucumber, features are tested with RSpec and Capybara but the features are still based on user stories.