In this KnowledgeKnugget™ you will learn how to apply step 3 to user story writing. As the author of user stories, you need to focus on writing user stories that the delivered solution will provide. Ensuring that your user stories are relevant reduces the time wasted writing and elaborating unneeded user stories.

An Effective User Story Is Relevant to Your Project

OK, you are a business professional. Someone has asked you to write user stories for a planned change to your information technology (IT) application. Being diligent and wanting to do it correctly, you have already viewed our first two KnowledgeKnuggets™ on “Rules for Effective User Stories”, so you already know:

Rule 1: An effective user story is a simple sentence that does not contain conjunctions or limiting phrases.

Rule 2: An effective user story emphasizes “what” the solution does, not “how” it does it.

Great, that is how you express an effective user story, but what about the content? What will make a good user story? It is time to discuss Rule 3, namely:

“An effective user story is relevant to the project.”

Project Scope Determines User Story Relevance

When you sit down to write your user stories, you need to consider what the project will deliver. In the world of IT, there are a couple of options for delineating what a project can and cannot do. What you are looking for is something called a “Project Charter” or a “Project Scope Statement”.

A Project Charter typically describes the project in general terms such as:

“Policyholders should be able to manage their automobile policies on the web. We need to support web-based policy payments and allow prospects to apply for and be issued temporary proof of insurance coverage pending underwriting rate approval.”

A Scope statement is usually much more specific, so it might read more like:

“This project will enhance our web-based Policy Maintenance System by allowing policyholders to interact directly with their automobile insurance policies via secure internet access. The web application will allow prospects to request temporary insurance coverage (pending underwriting rate approval), submit payment for outstanding premiums, and update personal and/or vehicle data. It will not support claims processing.”

Scope Statement versus Project Charter

As you can see, either delineates your project from the environment of the organization by establishing the boundaries for your project. Whereas the charter can be somewhat vague, the scope statement typically specifies business processes, functions, organizational units, roles or jobs, etc. that the project might affect or influence. It can also specifically exclude certain components (in our example, claims processing) to further clarify what the project will not do. The user stories you write have to fit pretty much entirely inside the boundaries that the project charter or scope statement define to be relevant to the project.

In an Agile environment, the Agile team will ask you to elaborate on the story when they are ready to start coding (which could be in a couple of months). In a conventional environment, the business analyst will do the same but before publishing a Business Requirements Document (BRD). In either case, discovering that your user story is not in scope for the project at that time is unsettling to say the least. If you express your user story so it is relevant to the project, you waste less time writing, elaborating, and discarding them. You also avoid bloating the backlog or requirements document with user stories that the project will not implement which saves considerable time for the entire team. The question is how you can ensure that your user stories are relevant while you write them.

… [end of excerpt]