The Necessity of User Stories

In agile scrum software development, we write user stories to capture the requirements of an individual feature within a software project. User stories are an effective way of capturing the necessary functionality of an entire product.

Typically, stories should follow the format of “As a <role>, I would like <goal>”, where functionality is described through the user perspective.  When building a product, user stories serve as a guideline with acceptance criteria to guide developers into building the correct features. While it is still necessary to understand the vision and purpose of the product, the intricate details of a product can be captured effectively through user stories.

Why Stories Change

Product definition is never perfect from the start. While we should define the product as thoroughly as possible, there are bound to be some parts that haven’t been accounted for or parts that could be improved upon. Part of the agile process is to be flexible and welcoming to change, and we believe this builds better products. Delivering in iterations gives us the ability to evaluate the product multiple times throughout the development cycle.

Changes should generally be made in the interest of creating the best user experience, simplifying something technically, or when the scope has changed.

1. User experience – we should always be striving to make a product that captures the ideal experience for the user. This can primarily be attributed to the UI design, but also based on how functionality ties in. Features and app behavior need to be intuitive and simple for users.
2. Technical – there are often some technical workarounds that aren’t easily visible in the product planning phase. Given that changing something on a technical level doesn’t compromise user experience, it can save project time with minimal drawbacks.
3. Scope – simply a change in the requirements. The scope is changed when it is decided that certain features do not need to be implemented anymore, or a feature has been pushed to the next release of the product.

How to Make Changes to User Stories

In all of the above cases, some form of change in the user stories is necessary. We can do so by finding the individual user stories on our issue tracker pertaining to the specific issue and modifying it to fit the new requirements. Note that some major changes (e.g. a scope change, change in business requirements, etc.) will likely affect multiples stories, thus all of them must be changed accordingly.

For example, if I were to change a button’s functionality from bringing the user back to the homepage to bringing the user back to the previous page, the process would be as follows:

Previous story

As a user, I would like to be taken to the homepage when clicking the back button.

Acceptance Criteria:

The user is brought to the landing page of the app once the back button is clicked.

New story

As a user, I would like to be taken to the previous page last visited when clicking the back button.

Acceptance Criteria:

The user is brought to the last page they were previously on once the back button is clicked.

Changes Make Products Better

Being open to change is part and parcel of remaining lean and agile. While it requires adaptivity and plenty of painstaking hours to get a product onto the market, it helps ensure a high level of quality. It is important to understand and accept that a product can’t be perfect from the planning phase, and being open to changing the product throughout the entire process allows for refinement and progression towards the ideal. Keeping an open mind throughout the development process allows us to implement ideas from anyone on the team, in order to create the best product.

If you’re interested in learning more about the Clearbridge development process and approach, shoot us an email.