Agile Software Development: an introduction to user stories
One of my favorite aspects of agile software development is how it encourages people to interact with each other, to be part of something, and to get involved. However, it still raises some challenges, like communication between business and developers, resource allocation issues, and estimation problems, to mention a few.
One way to handle those issues is by working with the information we know at the time instead of trying to predict the future. What also helps is to do it frequently, moving forward as we learn more.
In this post, I’m going to talk about user stories, a tool we can use to handle the issues I mentioned earlier.
What are user stories?
The definition of a user story can be as simple as an informal description of a feature desired for a software, generally written using terms familiar to the customer or user. People can use index cards, sticky notes, or software to write and organize user stories. Ron Jeffries wrote an article where he defines a user story as a sum of three things: card, conversation, and confirmation. Let’s explore that in more depth.
Card
Jeffries referred to the written part as a card since people use index cards or sticky notes to write their user stories. For those using software, there are many products out there representing stories like index cards or sticky notes. The idea is the same. People — ideally being from the business team — write short descriptions about a feature in a bunch of cards, each representing one functionality or part that functionality. Let’s look at an example.
Example 1: A user can pay our car rental fee using a credit card.
Note that there is not much detail on the card, only a primary reference to what business needs. The reason for that is the card part being just a reference to the related business requirement and not the actual specification. When relevant, the business team can add notes like the next example.
Example 1.1: A user can pay our car rental fee using a credit card. Note: only Visa credit cards for now.
Even with that note, the story is not ready for the development team to code it just yet. The development team will probably have questions and need more details. To answer those questions, we use the next component of a user story: the conversation.
Conversation
Having the card with our feature description, the business team gets together with the development team to discuss the details and answer questions. If the development team needs specific information, the user story might be divided. Each new item will represent parts of the original story, so they can be estimated easily. Another way is to add more notes or examples to the original card. Those examples are part of the acceptance criteria and lead to the last component of a user story: the confirmation part.
Confirmation
The last component of a user story contains examples of how the development team knows when the story implementation is complete. Again, it’s essential that the business team writes it, so they set their expectations for each user story. When using paper cards to write stories, the back of each card can be used to write the acceptance criteria. When using software, there will probably have a field dedicated to it.
Example 1.3: (back of the card)
Acceptance Criteria
- Only credit cards are accepted, not debit ones or others;
- The credit card must be a Visa credit card;
- The credit card cannot be expired.
The confirmation part is the glue between the card and the conversation parts. It helps to build trust by allowing the developers to show the tests running and letting the business learn that the team can and will deliver what is needed.
Want to learn more? Check the material below.
Books
User Stories Applied: For Agile Software Development, by Mike Cohn
Extreme Programming Installed, by Ron Jeffries, Ann Anderson, Chet Hendrickson
Youtube
User stories, by Mike Cohn
Does Everything Have to Be a User Story? Ron Jeffries & Chet Hendrickson
About the author
Eduardo Brasil is a Software Engineer at Poatek.