We all struggle at times with User Stories. You know – those allegedly simple and easy to write descriptions that captures what a user does or needs to do as part of his or her job function, and are used in software development as a basis for defining function or direction. Yeah, those.
Well, over the years, I have had a lot of lessons learned here, and below are some of the guidelines I try to follow when writing or advancing user stories. This by no means is to be considered definitive or cannon – but instead is just the general rule of thumb to help keep a customer focus, while at the same time trying to promote an agile environment.
- The User: Well, they don’t call it a “User Story for nothing”. Often overlooked in the User Story, is what the USER is experiencing and wants to see in the product. Considering that anyone can write a user story – why not take that customer message straight to the Development team? In our case, we offer the customer a bi-annual venue to place their thoughts and ideas out there for digestion. This method utilizes other items discussed in this article (such as Themes, Visibility, Collaboration and Decision) and gives true feedback outside of the ivory tower of the company. Another voice for customer are your Customer Facing Teams (CFT) such as Customer Care or Technical Support. If these Teams are doing their jobs correctly, they can be a great conduit of User Stories as they escalate issues through the chain. Conversation:
- Themes: As you can see from the picture at right, User Stories were grouped into themes to make it easier for proper triage and grouping by either the Product Manager or Owners as they determine what goes into the backlog. In addition, this type of grouping can aid in prioritization, as it gives a quick visual as to “What is important to the customer”
- KIS”: What more is there to say? KIS, or Keeping it Simple is essential on progressing a user story. By keeping to the point and using easy to understand language, we avoid any confusion that cause misunderstanding or delay. A good rule of thumb is that all of the information fits on a 3×5 card and uses the following format –
As a [Role]
I want to [do some action]
So that [business value]
Given [Initial State]
- Collaboration: Story writing is teamwork. When groups of people get together, the creative juices get flowing. In the case above, where we solicited customer feedback, Customer A might have made a suggestion, and Customer B (seeing A’s suggestion) was inspired and expanded up the idea and might have provided greater clarity or direction for a particular solution. Meanwhile, in a Scrum environment, you have some very brilliant people working together….leverage that creativity and knowledge. Get them engaged so that a single individual doesn’t run the team with his ideas. Interact with the Story Map to create a “living document” of the product backlog – don’t just create another document that is emailed around, filed away and never looked at again.
- Story Map: User story mapping offers an alternative for traditional agile planning approaches like the Scrum product backlog. Instead of a simple list, stories are laid out as a two dimensional map. The map provides both a high level overview of the system under development and of the value it adds to the users (the horizontal axis), and a way to organize detailed stories into releases according to importance, priority, etc. (the vertical axis). The map shows how every user story fits in the full scope. It is used to facilitate a Collaboration and provides a visualization of progress of a project. In the example below, it only takes a quick glance to see items requiring the most work, status and the progress of each. Consider the Story Map a type of dashboard – a visual tool to help you keep your pulse on situation.
- Start Big and get smaller: My mother had an expression, “Don’t let your eyes be bigger than your stomach”, ie- don’t take on more food than you can possibly eat. The same can be said for User Stories. While it is ok to start with large goal oriented Epic styles of stories, break them down into more “bite sized” chunks that are easily managed and ready to be product increment.
- Acceptance criteria: If you do not know how to win, why play the game? Always document the Acceptance Criteria so that the teams know what the true goal they they are shooting for is.
- Yes, No and Maybe: I bet my team wishes they had had a dollar for every time they heard me say this. Its key to remember, not every User Story makes it into the Product Backlog. You are going to have the glaring Obvious (Yes), those immediately identifiable as No and then the stories that are on the fence….the Maybes. Hopefully, everything subscribed to the KIS method, grouped by Theme and/or was openly discussed by Collaboration – thus being easily put in the Yes or No category. However, every now and then, an item gets through as Maybe….and it is imperative that these stories get addressed quickly and re-categorized, or else they are forgotten and fester.