Lets talk about user stories. Writing and appropriately sizing user stories is one of the first and continuing challenges for organizations adopting an Agile methodology. While similar to requirements in characteristics, user stories require some special attention to get optimal results. Below is an example of a user story layout.
Keep these three steps in mind for your user stories:
2. User Centric
No, that’s not a typo. Like your goals, user stories should follow the same principles, plus one, Simple;
S – Simple. The user story should be a simple item of work, not a complex series of activities. This is the heart of breaking a complex piece of work down into a number of simpler pieces that can be accomplished within the chosen iteration length. For example, a user story of ‘write and send next eZine article.’ is too vague, non specific, and feels complex due to its lack of specificity and simplicity.
S – Specific. Your user story should be specific about what is to be done. An example is: ‘Write up 2nd eZine article, format it using same template as 1st article, and ready it for distribution by selecting a target mailing list.’ This describes what is to be done, and provides enough information to begin work on the task. Note how this also defines done for the user story.
M – Measurable. Once you’ve written the user story, be sure your project team estimates the effort. Whether you use story points, hours, or some other estimation value, the act of estimating the user story will help vet the SSMART items and begin to open the discussion within the team about the scope and intent of the work.
A – Attainable. Ok, we have to actually be able to accomplish the task involved in the user story. By doing this we also support the definition of done.Â So writing a user story of ‘Achieve world peace’ is a worthy goal, but not very attainable for most project teams.
R – Realistic. Like being able to accomplish the user story, it needs to be achievable by your project team. Setting a user story that is far out of their reach will not foster success. There is more that can be said of exploratory user stories, and how to treat them and use them within a project. However, the bulk of a project’s user stories should be realistic and achievable by the project team.
T – Timely. The user story should be achievable within the iteration time frame, and have a time frame associated with it. This supports the Measurable aspect of the SSMART principle.
2. USER CENTRIC
User Stories are written from the user’s point of view and tell the story of what is to be completed.Â While this sounds obvious, it remains a difficult area for companies transitioning from Waterfall to Agile. A key concept for the project team is to clearly define WHO the primary user of the site is. If you design for everyone, it will be usable by no one. You can get a quick overview of persona’s on Wikipedia, which will reference much of Alan Cooper’s work . An example of a user-centric story aimed at the primary persona for the site is: ‘Jane Doe can upload her resume to the website, as well as provide up to 3 meta-tags for searching and up to 3 external links.’
Often overlooked, the success of Agile user stories is the ability to replan and reschedule the user stories as business needs change. Each user story should be as independent as possible to avoid entire blocks of user stories that must be completed together. This is one of the hallmarks of Agile, and one of the pieces that teams struggle with as they try to simplify and break down a complex task into multiple pieces.
Think broadly here, and consider using techniques like stubbing out database connections so a user story that depends on a database being created can still be completed independent of the database, and integrated later when the underlying structures are set up.
User Story Samples
Following are some sample user stories that I’ve used as a Project Manager that help illustrate some of the points in the article. Notice the green status dot showing that task has been completed.