One of my favorite parts of Agile Software Development (and the easiest to implement) is the Story Ticket Method. This is often referred to as the “As A”, “I Must”, “So That” method. It is a methodology to help teammates create tickets in standard fashion that is usable by everyone.
Let’s look at the construction of new tool shed in the backyard. If I created a ticket that said, “Build a new tool shed” there is no way to tell what kind of toolshed I might get. Just look below, here are three examples of very different tool sheds, yet each one is technically an acceptable tool shed.
Agile Stories allow the author to better describe the particular task at hand so that anyone can understand it regardless of their position or trade. It also forces tasks to be more narrowly defined resulting in smaller pieces of tasks all relating to the larger task.
An Agile story has 3 main parts.
- As A…
- I Must….
- So That…
For example. “As A gardener, I Must have a toolshed, So That I can house my tools”.
This is the basic example of what an agile story is. It has the three needed components which allow us as readers to understand the task better. However in this example it is still way too generic. The story as is offers no specifications of any kind for the toolshed. This is again where the benefit of agile stories come into play.
“As a Toolshed, I must have a roof, So that the contents inside stay dry”. This example helps us understand that part of the toolshed’s job is to protect the contents within from outside elements such as the rain. When we create the roof we know that it must be a waterproof roof. We are not specifying whether it needs to be slate, tar or shingles… but maybe we do or do not want to add those details.
“As a Toolshed, I must be taller then 5 feet, So that I can hold items such as rakes and shovels”. This example gives insight into what might be held inside so that we know how tall the shed must be.
“As a Toolshed, I must be wider then 10 feet at any dimension, So that a lawnmower can easily be stored inside”. This example gives insight again into what will be stored inside and helps the user to know how wide the shed must be.
Just from these 3 simple agile stories we have a much better picture into what type of toolshed needs to be built. In fact we can see that out of the three example tool sheds above, only one matches our requirements so far.
A toolshed is a very large project and as such will most likely require a large number of user stories. To keep thing organized you want to create your user stories into logical separations. For example you would create a new user story for each requirement or feature of the tool shed. The door would be one such requirement. A window on the south side would be another requirement. And so on.
In software development you might see stories such as below:
“As a CS Agent, I must have an admin tool to reset user accounts so that I can assist customer service requests.”
“As a software developer, I must have access to XYZ software so that I can program effectively.”
“As a user, I must have a registration form so that I can create an account with a username and password.”