Ok, you are a Business Analyst, someone has asked you to write user stories for a planned change to your information technology application, being diligent and wanting to do it correctly you’ve also viewed our first two 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’s how you express an effective user story but what about the content, what will make a good user story?

It’s time to discuss Rule three namely; an effective user story is relevant to the project. When you sit down to write your user stories you need to consider what the project will deliver.

In an agile environment the agile team will ask you to elaborate 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 or BRD.

In the world of IT there are a couple of options for delineating what a project can and cannot do, what you’re 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 project scope, risk, assumptions, constraints etc…

As you can see either delineates your project from the project of the organization by establishing the boundaries for your project. Whereas the charter can be somewhat big, 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, example what the project will not do. The user stories you write have to fit in pretty much entirely inside the boundaries that the project charter or scope statement define to be relevant to the project.

To summarize, the third rule of effective user stories, an effective user story targets components that are relevant to the project and that it falls within the project charter or scope statement, defines something about the solution that the business community needs or wants and has a short tail, does not create a cascading effective changes that exceed the project’s authority. Keeping your user story relevant will save you and the project time and money and make you much more popular with the IT department and who knows where that could lead.