Can User Stories be used in Waterfall Development?

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.

A pragmatist’s view: What is Technical Architecture and how do you do it?

As a Technical Architect in a digital agency I am often am asked what the role actually means or does. This question comes from everyone including Technical Architects (TAs) and one that is actually quite difficult to answer. The reason for this is that the definition of Technical Architecture in the real world has a very broad scope and is different in different companies, projects and from person to person. It is often becomes a religious argument what being a TA means or what the best way of doing it is. Forgetting best practices, patterns, methodologies, techniques and opinions just for a minute, here a broad view ‘what’ a Technical Architect does and ‘how’ they do it. I'll even look at why in some cases. I'll leave where and who up to you.

Back to the Estimate

The life of a technical architect is one filled with magic and wonder. We often wonder how to perform expected feats of magic. Forgiving such poor word play, there is one duty we are faced with in our day to day that demands such a skill. This is The Estimate. Being asked to estimate for a project can be like magically predicting the future. Often with a lack of information, people to consult and pressure from the business to come up with the magic number that turns a profit and doesn't send the client packing, it is easy to get it very wrong. Like Marty McFly in Back To the Future II, how do you avoid a dystopian future where you've been fired, your music career is wasted and your wife’s turned out to be a bit of a bloater? Since you probably don't have a flux capacitor, your next best option is to abide by Tech Rash’s top tips for project estimation.