User Stories: Bridging The Communication Gap Between Customers and Developers

Most web site development projects fail through lack of communication during requirements gathering. A disconnect between clients and programmers often occurs due to software being an intangible object. Unlike purchasing a car, developing software relies on clients describing desired functionality and programmers interpreting that description to create a tangible product.

As developers, we often hear “I don’t care how you do it as long as it’s done by June and costs X”. The programmer often shoulders the burden of trading quality for additional features, partially implementing features due to time, or must otherwise make decisions the customer and users should provide input for.

When the customer shoulders the burden we typically see lengthy meetings at the beginning of the project where functionality is stripped away, then when features are delivered, they have less functionality than initially anticipated.

What we need is a way to work together so that neither side dominates and so that both parties are held responsible for the outcome of the project. Projects fail when one side dominates and resource allocation falls entirely on one side.

Creating user stories is a great way of opening discussion and bridging the communication gap between the client and technical team. User stories created by the product owner (typically the client) are written in a non-technical format that fulfills a business requirement for the website. The technical team then creates technical tasks to satisfy the client’s business requirements. Creating the tasks (scope) of the project this way allows everyone to understand what is needed to satisfy the requirement.

How is the User Story process different from the typical Waterfall process?

First, a project with user stories will have a different rhythm than you may be used to. A typical waterfall process usually consists of the customer and developers scoping the entire project at the beginning. Then, the developer goes away for a few months, develops features based on the customer’s requirements. Finally, at the end of development, the developer and customer come back together to accept the work.

If you’ve been involved in previous development projects, it’s at the point of acceptance that the customer wants various tweaks to the look or functionality of the website. If you’re lucky they are minor tweaks, but more often, these changes can take hours, days and possibly weeks of reworking to satisfy the customer. It’s at this point the relationship between the client and programmer can become “hostile”. The customer pushes for changes. The programmer pushes back and asks for a Change Order and the relationship typically becomes fragile.

Using user stories throughout the project life-cycle keeps the customer very involved throughout the duration of the project. This is true whether the using Scrum, Extreme Programming or a home-grown process.

The customer’s involvement in writing stories, approving tasks and reviewing features very early on and throughout the development process significantly reduces the risk of scope creep at the end of a project. It also provides a level of benchmarking throughout the project allowing the customer to see stories completed, hours used, etc. Most of all, it bridges the communication gap found in many development projects.