Project Agility

Innovation teams are often small, multifunctional crews tasked with constant prototyping.  Being open, communicative types, they find Agile useful for most projects.  Those teams often encounter a common prototyping pain point: Who writes user stories when we don’t have any users?  Agile hangs its hat on its ability to respond quickly to user feedback, to create user stories from that feedback, and to release features and content that address what users are demanding at that time.  When you are prototyping, however, you don’t usually have users and the traditional user story:

As a (user type/persona), I want to (insert desired action) so I can (insert revolutionary motivation here).

Without users to provide feedback, and without a product for anyone to provide feedback on, how do you address the issue of User Stories?

It’s Not Just Requirements

It’s tempting to slip back into a requirements mentality with a prototype.  Don’t do it!  You’ll miss all the benefits of that last half of the user story: “so I can (insert revolutionary motivation here).”  Requirements usually – and rightly – provide specific technical, compliance, and integration direction for whatever you are building.  You need those things in prototype or new product development.  You also need real User Stories and you need them before you design and engage in release planning.

What Should We Bring to Release Planning?

There are different beliefs on Iteration Zero, whether it does or should exist.  For convenience, let’s call whatever you do before your first release planning session iteration zero.  Here’s what you need to gather:

• Compliance Requirements – These usually come from your product owner, company SME or, if you’re lucky, a compliance and quality lead from your team.  These requirements usually already exist and cover all your applications and projects.
• Integration Requirements – This set usually comes from your technical lead and system administrator, both of whom will understand, based on a high level charter, how and where the new prototype will need to fit into existing systems. 
• Charter – This usually comes from the product owner.  It is a result of the Product Owner’s being a liaison with the company/sponsors before the project team even sees the work.  Charters should contain the high level goals of the application or prototype, the types of customers it serves, basic expectations around its release and performance, and authorization to do the work.
• User Stories – How do you get them?  It’s not as difficult as you think.

Gather Investors and Get Their Stories

Every project has parties interested in the company.  The Product Owner can educate them on the need and the format of a User Story.  In most cases, a Marketing/Product Manager, Sales Representative, Customer Champion, or Customer Service Representative can provide you with a starting list of user stories that cover basic functionality.  The Product Owner will have a harder time prioritizing and pruning user stories from these highly-invested “customers,” but it’s part of a Product Owner’s role to make the hard decisions about what the “thing” should do first, most and best.

In short, when there are no users, talk to people closest to the users for whom your work is intended.  Keep the list short and make it just enough to get to production.  You’ll be able to provide true user stories soon enough!