A Good Story
Throughout my years of working in software development I’ve become increasingly aware of the value in writing good stories, tickets, tasks. What they are called isn’t important, what it is, is.
What is a story?
A story should be a meaningful amount of work that needs done for some amount of business value. That value can be increased revenue from a new feature, a bug fix or a security issue resolved. All of these have business value. Some are more obvious than others.
A feature provides value by increasing revenue or decreasing costs. A bug fix provides value by increasing customer satisfaction. A security issue resolved provides value by decreasing risk. One of the things to identify in the story is the value provided. When writing a story, if that isn’t obvious, ask the question, “What value does this provide?”.
What makes a good story?
A good story should describe the outcome that needs to be achieved. This is frequently done by phrasing it in terms of a user story.
As a user, I want to be able to do X so that I can achieve Y.
This is handy because it describes the outcome that needs to be achieved and the value that it provides. It also helps to identify who the story is for. This is important because it helps to identify the acceptance criteria.
Without this, a story can be vague, confusing and difficult to understand the objective. Having this information readily available means the story can be worked immediately and prevent the need for additional communication.
The user story should be explicit in what the outcome is, without dictating how the work is achieved. The benefit of this is the actual execution is left up to the team to determine how to resolve the story. This allows the team to be creative and come up with the best solution to the problem.
What makes a bad story?
A bad story is one lacking in detail, overly detailed or a combination of both. The story should be more than just a title. I’ve frequently seen stories just be check lists, for a single engineer on a project this might work. But as soon as you have multiple engineers working on a project, this becomes a problem.
A bad story:
Tag the resources
A good story:
As an engineer responsible for AWS costs I want to ensure our resources are tagged so that we can identify the cost of each resource. Currently in the development account resources are missing the appropriate CostCenter tag. Ensure all lambda resources have the appropriate CostCenter tag.
The story should be detailed enough that anyone on the team can pick it up and work it. This is where the acceptance criteria comes in.
What is acceptance criteria?
Acceptance Criteria is information for the engineer working it to know when the work is complete. This is helpful because it keeps the scope of the story small. If the acceptance criteria is do this giant thing that is a bad story. It should be broken down into smaller stories.
Remain agile
Finally, remaining agile is key. A story for one team, doesn’t always work for another. These are just general guidelines. If you find something that works better for your team, do it. The goal is to deliver value to the customer. If you can do that better, do it.
Be willing to make changes in your stories and in the process. If writing the story is time consuming and annoying for your team, change it. I’m not saying it will be enjoyable to write stories, but it shouldn’t be a burden.