User Stories and User Focused Development
Our startups are most often comprised of technical talents, with some experience in software development. But that isn’t always the case. Insight and innovation can come from many quarters, and we also take teams with little technical experience, but plenty of drive and vision.
Getting a software engineer to help you execute a vision, even a complex one, doesn’t have to be too difficult. But it can be overwhelming for both the entrepreneur and the engineer, when they don’t know how to speak each other’s languages.
To non-technical founders, a software engineer can seem sort of like a Jedi Master. He’s wise, but he only answers questions in ways that make sense to him.
We sat down with one such startup this week, and they had a pretty straightforward issue. Where do we start? We know what product we want to build, but what do we ask our software master to do first?
User Focused, Not Feature Focused
We constantly preach to our startups about being user focused. That isn’t just a philosophical stance or an attitude. Agile development means explicitly stating the outcomes that users will experience, and executing around those outcomes.
A truly agile team expresses the results of their work as a necessary precursor to doing the work, making sure that they aren’t wasting time on things that don’t have the user experience and user outcomes in mind. Just as a positioning statement is an expression of what a company is, as defined by the problem it will solve, and for whom, user stories also revolve around solving problems for users, and accomplishing user oriented goals.
The Agile User Story
In agile development, a “user story” is a way of talking about an imagined functionality or feature. It usually follows a template like this: As a <type of user>, I want <some goal> so that <some reason>.
A product roadmap may contain hundreds of such user stories, describing the minute functionalities of the service. These stories can be told from many different perspectives; from that of the user, the administrator, the power user, the first time user, or others.
These stories can range from the simple to the complex. A simple user story, like As a user, I want to view the FAQ, so I can get help, might be accomplished in just a few lines of code.
Other stories may involve a long list of sub-stories, detailing the steps necessary to accomplish the user goal. So, for example, if you needed to include a functionality that allows a user to recover their password, you would put it this way: As a User, I want to recover my password, so I can log in. But that story might include a whole subset of stories: As a user, I want to request a password reset, and then, As a user, I want to reset my password using a link sent to my email, followed by As a user, I want to enter a new password.
In addition, “conditions of satisfaction,” can be added to even the simplest user story, as a way of ensuring that the functionality or feature will work as intended.
For example, we might add certain conditions to the above user stories like:
- Make sure the user gets the recovery email right away
- Make sure the system doesn’t allow the recovery email to be sent twice in under 5 minutes
- Don’t allow the user to enter the same password as was previously used
- Don’t allow the user to reset the password more than once using the same link
These conditions set further tasks for the engineer, and will help define a successful iteration of the feature or functionality.
Mike Cohn, of Mountain Goat Software, does a great job of explaining this process in his post on User Stories.
Who Are User Stories For?
In a small startup with an agile approach, the whole team can generate user stories. A user story can come up as a new feature idea, or as something to fill a missing functionality that is needed to make the product viable.
And user stories don’t just affect customers and users. They need to be generated for other users of the product, including administrators, and even other products and programs that may interact with yours.
It’s the job of the product owner (the person ultimately responsible for the timeline of development and priorities), to decide which user stories should be addressed in which order. It’s the job of the software developer(s) to implement the stories as code, and the UI designer to give visible access to those functionalities to users.
At the beginning, when very little code has been written, a set of user stories is very useful in developing a product roadmap. Features and functions have to be prioritized, and by grouping user stories into two or more large categories like: “MVP,” and “Future,” you can begin to get a rough sense of the work needed to launch a product, and what that product will contain.
Agile projects work based on a prioritized backlog- with the engineers and designers working on the highest priority stories first. This can help a product owner strategize, and avoid wasting time on developing features they would like to have, but which aren’t as important as developing the MVP, or keeping it working.
