If you work in the business of software development you most likely have come across User Stories. If you aren’t familiar with them, or are all of a sudden being asked to write them or deliver them and aren’t quite sure what they are, here is a brief background.
User Stories are born from Extreme Programming (XP) and Agile Development Methodologies. XP and Agile development is essentially a set of principles and practices which have emerged over the years (XP was first coined in 1999) to address with the challenges of software development and fulfill a goal of delivering working software as early as possible.
User Stories fit mainly into the requirements gathering and definition phase of software development. They are Agile’s answer to transforming what is often an onerous, expensive, confusing, obscure and inefficient process to one that is lightweight and effective, and drives the software development process towards delivering valuable software features early.
Like many other aspects of Agile Development, User Stories are becoming adopted as an industry standard way of describing software requirements.
The benefits behind writing requirements in this way include:
- Writing requirements as User Stories makes them easy to understand i.e. they eliminate technical or domain jargon
- Writing requirements as User Stories helps validate their value to the users of the application
- User Stories can be delivered independently and in short iterations, allowing the ROI from working software to be realised earlier
However, because User Stories are being appropriated by different organisations who deliver software in less agile and more waterfall ways (wagile, scrumafall, etc) and don’t have all the other Agile practices in place, there is often confusion around what a User Story is and how they can be used to describe, specify and deliver a solution.
In my experience, this is often the case where an Agency or Software House (Delivery Partner) is tasked to define, cost and deliver a new build for a Client.
In this scenario, the following constraints often apply:
- The Client has a maximum budget to get the solution built
- The Client has a massive wish list of requirements
- The list of requirements exceed the budget
- The Client wants to know what they are going to get for their budget at the beginning of the project
Given this starting position, the Delivery Partner has the challenge of defining and delivering a solution which has as many of the items from the wishlist within the budget constraint. So faced with this challenge, can User Stories be used to define and cost a fix priced build?
The short answer, I put forward, is yes with a caveat that User Stories go through the following steps to turn them into a scope of work that can be delivered within a budget.
