While big enterprise tends to have greater access to resources and more leeway for risk taking, SMBs have the good fortune of being agile. With less red tape to cut through and fewer rungs to climb on the decision-making ladder, they can act swiftly.

With this in mind, it’s heartening to know SMBs can adopt key practices of big business, and often produce better results. One such practice is agile development, which large companies have increasingly come to rely on.

Flexible Muscle

Giancarlo Lionetti, who works with engineers and designers at Dropbox, offers insight into how SMBs can benefit: “At the core of agile methodology is flexibility, and that’s a big part of what makes it so effective.

“Agile makes it easier for you and your team to focus on the immediate tasks at hand, but it also lets you easily move future plans around — so you can keep projects aligned to current priorities, even if those priorities frequently shift (which is the case in most industries these days).”

This sentiment is shared by Sharon Hurley Hall, who writes that agile development methodology helps businesses “speed up the development of products and services that meet users’ needs.”

A major part of agile development is writing user stories, which refers to what intended users want from the product and how that product can help them achieve a specific goal.

If you thought to create convincing characters with real challenges and goals was a task reserved for novelists, then it’s time for a reappraisal. This skill also forms a vital part of the job for agile software developers, for whom writing and telling effective user stories can make or break a product.

Before we think about writing, it’s useful to heed Roman Pichler’s advice: “If you don’t know who the users and customers are and why they would want to use the product, then you should not write any user stories.”

The logic is simple: Initial research such as observing and interviewing users needs to happen, or you run the risk of “writing speculative stories that are based on beliefs and ideas – but not on data and empirical evidence,” Pichler says.

The Basic Structure of a Good User Story

So, how do you tell a good user story? Firstly, you need to know why you’re telling it, who your users are and what they need the product to achieve. It’s worth thinking of this in terms of a basic structure:

As a <user type>, I want <feature/function> so that <benefit>.

The above template is ubiquitous among user story writers and always requires these three elements for the story to be complete. Think of it like a general equation that requires you, on behalf of your user, to input individual values in order to produce meaningful results.

So, who is your user? It depends entirely on your product. Say you’re designing a program for a website administrator. How about we give our administrator some character, a bit of personality or even a name? Winona the website administrator has a specific want from her product, or put in terms of our structure: Winona wants a feature that allows her to disable multiple user accounts at once. Why? So that Winona can benefit by removing all accounts that have been inactive for a month or more with one command.

The structure can be used with any variables, and your user could be anyone who will use your product to complete any number of tasks. The important prerequisite, however, is to define the users properly and ensure that not only do they want to do something, but they have a goal to achieve through their actions.

Travis Birch says that when writing user stories, keep three Cs in mind: card, conversation, confirmation.

The first C is important. Stories should be written on cards and displayed for the team to see. This practice shows stories don’t have to be brought in for discussion fully formed. “It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it,” Birch writes.

Before moving onto the other Cs, let’s talk about specifics.

The Devil in the Details

How much detail is required in a user story? The user should be relatively complex. You don’t need to know whether they take sugar in their tea or the name of their dog, but you do need to think of them as real people with wants that can be achieved.

Alex Cowan writes how valuable it is to build a persona for your user. This usually includes — in addition to a name, a job title, a want and goal — a few hypothetical questions that could be asked of them. Cowan suggests asking what makes the user tick and who in the world is a real example of such a person.

Of our expository Winona, we could ask her how many work hours are spent deactivating accounts one at a time, or how frequently she needs to remove inactive accounts. The importance of this task is the chance to humanize a user and understand the requirements of his or her role. After all, users are real people who rely on your software to help them do a better job.

A second point about detail concerns the story as a whole, rather than the characteristics of a user.

You may have heard the word “epic” used to describe an overarching user story. This just refers to a big user story that requires multiple sprints in order for kinks to be ironed out and user experience optimized. As Ronica Roth writes, “A story should be small enough to be coded and tested within an iteration — ideally just a few days.”

Epics start with broader scope and fewer details, but lead to smaller and more refined user stories with highly specific details and measurable wants and goals. Essentially, they are too large to be a user story and are usually less of a priority.

Epics won’t be tested in one sprint and often require two or more, Mike Cohn writes at Scrum Alliance. Instead, they need to be broken into smaller parts, such as in our original example of Winona. These smaller stories can be tested and tightened in single sprints so Winona, and all other users, can achieve the want of removing accounts that have been inactive for a month or more.

Although Roth doesn't call it a Goldilocks test, she suggests finding the “just right” level of detail.

• Too broad: A team member can view iteration status.

• Too detailed: A team member can view a table of stories with rank, name, size, package, owner, and status; then can click a red button to expand the table to include detail, which also lists all the tasks, with rank, name, estimate, owner, status.

• Just right: A team member can view the iteration’s stories and their statuses with main fields; view the current burndown chart on the status page, and can click it for a larger view; view or hide the tasks under the stories; and edit a task from the iteration status page.

Tom Meloche offers three important reasons why user stories can turn out badly: They are written for people who are not actually users, they have no end users or their tasks are written as stories.

Collaborate

If you’re getting the hang of writing a user story, that’s good. However, it’s worth noting the writing plays a secondary role to stories’ discursive functions.

Birch’s second C is for conversation. The best way to achieve this is to have multiple members of your team write a few user stories. This way, individual team members better understand how to approach their own work from the perspective of the end user.

It also invites collaboration within the team to generate a broad range of user stories to help with initial development (or to keep in the bank for future testing and upgrades). Collaboration means plenty of discussions, which really is the whole point of user stories in the first place: how developers can optimize software so users can complete tasks more efficiently.

The writers at Playing with Cards suggest user stories be written at the beginning of a project “in order to create a backlog of all the functionalities that will be added in a release cycle.” However, stories can also be added throughout the project should that be required.

Acceptance Criteria

It’s a good idea to have a set of acceptance criteria on hand to ascertain your progress. The Yodiz blog offers an interchangeable phrase, “conditions of satisfaction,” which “provide a detailed scope of the requirement, which helps the team to understand the value and help the team to slice the user story horizontally”.

Let’s use another example. Your user story is: “As a poet, I want to provide my details on the website’s competition page so I can submit my poem.”

When testing if acceptance criteria have been met, it’s worthwhile using the phrase ‘it’s done when X or Y’ – inserting whatever your conditions may be. In our would-be poet example, we could say:

• “it’s done when the user/poet knows where to find the competition page.”

• “It’s done when the user/poet knows how to register online.”

• “It’s done when the user/poet knows how to submit his/her poem.”

Birch’s third C is for confirmation. In addition to the acceptance criteria being met, a story is confirmed when the product owner says the story is complete and considered “done.” The team and the product owner then check the “doneness” of each story in light of the team’s current definition of “done.”

More Than Just a Story

User stories are valuable tools but are only part of a bigger whole. Bill Wake employs a useful analogy. Think of the whole system as a multi-layered cake with network, persistence, logic and presentation layers. A user story is just a part of the cake, but the customer needs to appreciate the baked goods in its entirety. The best way to do this is showing them the cake before slicing vertically through the layers.

When written concisely with real users in mind and the bigger picture in sight, user stories can hone product development. Developers benefit by creating a great product, one that users will want to keep using. This feedback loop is vital for any product development and processes, especially for SMBs.

Agile development equips SMBs to be responsive to the needs of customers and the market. It’s about collaboration, active testing and the ability to change direction. In many ways, agile is about more than just process. It’s about ideology.

images by: Jakob Owens, Jeremy Cai, Jonathan Simcoe, Annie Sprat