User Stories are an artifact of SCRUM, a common but not ubiquitous methodology built on Agile Principles. As a Scrum Master and Agile coach, I guide the team on User Story creation and adherence to the Agile Manifesto and Principles. I’ve found in a few projects that User Stories can sometimes get in the way of the work, violating Principle Ten,
Simplicity, the art of maximizing the work Not done is essential.
User Stories Hurt When They Bind
The strain tends to occur in the grey area of Scrum work translation, deciding on the granularity of user stories and when user stories become tasks. I’ve guided teams, to my shame, through three hour meetings where we break down a sketch of a feature into detailed user stories, field by field, simply because that was what the company’s agile methodology demanded. I found no value in those stories as we actually delivered the feature.
A key example is our login component. Having a full user story around the First Name field on the login component was not helpful. We knew we needed a First Name field because the Component level story explained, clearly, that the user wanted to enter their information (story front side below). Frankly we had common sense and a set of acceptance criteria on the back side (story back side) to guide us.
We found that we referred to the sketch and architecture diagrams when building the front and back end, and the tester built all testing scripts based off a secure login scenario for an existing user. We had no need for a specific story for one field. It was an unnecessary barrier and a waste of time. In fact, we discovered that the process of Deciding what we wanted to build was taking longer than actually delivering it. This process of Deciding was labeled Discovery and User Stories became a product of this process, each story being a complete set of instructions for a specific feature or component. The level of story was based around what we felt could be built within one two week sprint.
Discovery – Building Stories Where There are None
During Discovery we have no user stories representing actual; work. As you can tell we do relate all our Discovery work back to a story card (blue card on the left). This story was the front side of the feature or component. The back side, the acceptance criteria and support documentation were being developed as part of the Discovery work occurring within the sprint.. We found that relating our work back to a User Story was much more efficient than creating a user story for each field, action or navigation element, a process which requires you to do all the ‘deciding’ before you write the story.
It is important for me to note that this project did not have an influx of user input from actual users. More often than not I find that a client is standing in the user’s shoes to create user stories on their behalf, more often than actually translating real user input.
User Stories as Testable Requirements
In another project, a streamlined agile team of developers worked exclusively in GitHub. They wanted as little documentation friction as possible that also met minimum company compliance standards. On this team stories = business requirements. The actual development work was phrased and displayed much differently to make sense to them. Their solution? Use ALL the tools and features of Github. I’ve already discussed the benefits of one tool they used in another post, Huboard: A Kanban board for GitHub.
Each user story became the development requirement. It was stored in a feature file on the repository and written in gherkin, a business language parser of real language. In short, the user story became the test, written in real english. The user story became both the requirement and the test. The tests were submitted to Selenium and run upon commit of code from the branch to master. Automated test scripts were built directly from a user story. Efficient, completely contained and sustainable. Also thoroughly documented and audit-able.
Use Stories, Don’t let Them Use You
My examples serve to prove a point. User Stories are not demanded by, referenced, or even clearly described in the Agile Manifesto and Agile Principles. Period. I’ve posted them here in case you wish to prove me out. User stories are an artifact and a tool to help you achieve Principle 1, customer satisfaction, and in support of all the others. It is a support, not a crutch. I have a short list of beliefs around User Stories and work in Agile. I’m sure it will change as I grow as a practitioner.
User Stories and Work:
My humble opinion
- All work should be related to, and be able to stand in line next to, an applicable User Story.
- Work need not be written as a User Story. Work should be represented in succinct, do-able units no longer than a sprint.
- All work should have acceptance criteria or a definition of DONE.
- All work should have an owner. That owner may not complete all the work but owns seeing it through and driving collaboration.
- All work should be decomposed into tasks. This serves to communicate clearly to the team rather than keep the work owner accountable.
- Each User Story should represent a specific type of user with a specific type of need and motivation.
- Motivation, the ‘So That I Can” portion of a User Story, provides the most value to a team in developing a solution to the problem as it most closely describes how a user expects to get what they want.
- A User Story can reference other necessary supporting documents or tools that help describe the solution.