It's the third week in a row that your team has given the same update: "We are almost done with the 'previous orders' feature." You are frustrated with the lack of progress and the inability to shift to more important work—like that feature you wish the team could start work on. Often the work specifications that developers build from are too large and vague. They are paragraphs about the entire feature, resulting in development work that cloaks progress from the stakeholder's view.

As a lead consultant, I have helped many teams get out of this same situation by showing them a technique that increases progress visibility and maximizes for re-prioritization. This same technique can help you, as well! The secret is to write smaller User Stories.

In this article I will show you how to craft small Acceptance Criteria for User Stories from a typical description of a feature, using the example of a “previous orders” page.

How do you make stories smaller?

A User Story is a feature description that is used by an engineer to implement software. It consists of two parts, a user scenario and acceptance criteria. A User Scenario provides the outcome a user is pursuing, whereas the Acceptance Criteria suggests an interaction with the UI to achieve that outcome. Small User Stories are written to be features that when completed could be deployed to production. Each one contains the minimal change to the program that will increase a user's perceived value of the application.

We do need to make sure a story isn't so small that users don't find the delivered feature worthless, while also making it small enough that the engineering team enters into a rhythm, a cycle in which work is continually delivered and deployed to users. This allows engineers to feel a sense of accomplishment, users get more of what they want, and stakeholders see progress toward a goal.

"I want those benefits, but how does this work?" you ask. Well, let's walk through an example

Here is a description of the “previous orders” feature that follows the typical industry pattern:

A logged in user can see all previous orders sorted by date. Clicking on an order reveals the products that were in that order. At the bottom of the order detail page, there is an email link for customer support.

Notice that the description focuses on elements on the page, and not on the new task users will be able to perform. This type of description is usually accompanied by a design mock-up, containing features not mentioned in the description. The companion mock-up to this story includes a "reorder" button on the order detail page, and the ability to filter the “previous orders,” leaving us to wonder if we are supposed to build those.

The first step to making this work smaller is to convert it to a narrative style, with the user as the central focus. We will use a format called Gherkin which includes the keywords Given, When, and Then (And is also included). This style describes where the user starts their journey, what actions they take, and what they are ultimately able to do (or see).

Let's write our first Acceptance Criteria!

We start by describing where the user is at the beginning of the feature. In this case they are logged in, otherwise they wouldn't have any previous orders. So we write that from the user's perspective, starting with the word Given.

Given I am logged in

Next we describe some action the user takes, with a When clause.

Given I am logged inWhen I click on the "previous orders" link

Lastly, we describe what the user can see in response to that action, implying that the application needs to change.

Given I am logged inWhen I click on the "previous orders" linkThen I see a list of my orders

This is a good first pass. We have taken one of the features in the description and written it out as Gherkin. However, it is important to ask yourself, "Would I deploy this feature?" If the answer is no, then the story is too small. When you take the time to understand what problem you are trying to solve for the user, it will lead to insight on how to make stories the ideal size.

The "why" behind the “previous orders” feature is that the company wants to make it easier for users to get support for order issues. With that information in hand, try increasing scope slightly, by adding a way to email customer support.

Given I am logged inWhen I click on the "previous orders" linkThen I see a list of my ordersWhen I click an orderThen I see an email link to customer support

Now that we have one story that we would deploy to users, let's write another one by finding another feature in our description.

In this next story, we iterate on the customer support behavior by defining an order detail page. The email functionality from the previous story is moved to this page, and additional details about the order are displayed to the user.

Given I am logged inAnd I am on the "previous orders" pageWhen I click on an orderThen I see its total price, date, sales tax, shipping cost, and a link to email customer support

You will notice that this story excludes displaying each product on the order. By limiting the scope of the story, we can balance tracking progress and delivering value. We want to see this new functionality finished in a day or two, not weeks.

Now that there is an order details page, the last logical step is to go through the effort of displaying each product that is part of the order.

Given I am logged inAnd I am on a specific previous order pageThen I see the image and price of each product in that order

Using these techniques, it is possible to write out all of the functionality described in the original work description. I’ll leave writing the “reorder” button and filter stories as an exercise for the reader.

Making progress

With the stories being worked on, you watch in amazement as each one takes the engineers around 1–2 days to complete. This increased rate allows you to better track progress.

Now that the work is small, every few days a story is completed and shipped. This gives the user something new, but it is also a chance for the business to shift focus. It is now possible to start more important features without putting a pause on existing work—since it is already complete. An example of this is: before work starts on the “reorder” button, you can shift priorities to a different feature. And the team can begin right away!

Small User Stories are one of the cornerstones for working on an agile team, they allow the team to fall into a rhythm in which every day or two a feature is completed and shipped. Progress is visible, priorities can turn on a dime, developers feel a sense of accomplishment, and users get the features that solve their problems sooner. I know this technique will serve you well.