Scope definition through User stories


User stories

The benefits of achieving a working software in less money, better risk mitigation mechanism (because you test early and test often) and dependence on process not individuals is one of the key reasons that XP has become one of the most preferred software development methodologies in recent years. Agile practitioners term User stories to be “Technique of expressing requirements as user stories to be an effective approach on all time constrained projects and are a great way to begin introducing a bit of agility to your projects & requirement management approach.”

If you happen to be one of those PMs who need to deliver your project in such fashion chances are you are most likely to use your scope statement e.g. project requirements in terms of user stories rather in standard functional requirement document. Hence it would be invaluable to know how you can employ user stories to define and plan project scope.

What are user stories?

A user story describes what functionality is required from the perspective of business users in simple or plain English running through different steps or stages to accomplish desired functionality. In simple terms, a user story provides the clear understanding of who wants the functionality, how it would work and why this functionality is required. In most cases user stories are written by customer or a customer representative working with a developer where developer may ask some questions to clarify the user actions but does not influence the idea creation process. User stories are used mostly in agile software development methodologies to provide the basis of features required in the software.

Development Process: While business user or customer narrates the scenario, developer makes notes on a 3×5 inch Card with functionality or requirement name, user action description, test condition, rough estimate and any other relevant point. For example, ” As a business user I want to be able to search for my customers by their first and last name,” or the “Application starts by bringing up the last document user was working with.”

The 3 basic tools used in the process are namely, Card as mentioned above, details around Conversation where details are noted as discussion with business user happens and thirdly Confirmation or Conditions that must be met for for the basis of user acceptance.

In case there is any ambiguity on the user story or it is deemed complex or too big the process of refinement is repeated until the story is concise and agreed by both user and developer. Please note the user story is not supposed to be definite business functionality and changes to the functionality are accepted at the time of development or even testing. From that perspective the process represents one of the key features of Agile development.

Advantages: User stories are a quick way of eliciting customer requirements without having to spend too much effort on formalized requirement documentation and bypassing overloaded administrative tasks for maintaining them. The purpose of user story is to respond promptly with less overhead in rapidly changing real-world requirements

Limitation: since the User stories are informal way to elicit requirement the test scenario for acceptance purposes should be in place without which the implementation of the requirement do not have customer acceptance.

Shyam Verma, PMP, ITIL
Program & portfolio Mgnt professional
LinkedIn:spverma. Twitter: Shammy1

There are three basic tools used in the process namely Card as mentioned above. Secondly details around Conversations where details are noted as discussion with business user happens and thirdly Confirmation or conditions that must be met for acceptance.
Advertisements

2 thoughts on “Scope definition through User stories

  1. While user stories are definitely a good way of stating the requirements, the core objectives of a Functional Doc is to describe all that is done by a user, all that is required by a user and all why the software needs to be deployed for that customer. Due to lack of this understanding, PMs many times “forget” critical user stories and hence the heart burn late in the dev cycle among the developers. Keeping the objectives in focus, user stories are best way to describe software requirements.

  2. I believe this is one of the most important information for me. And i am glad studying your article. However should observation on some basic things, The web site taste is wonderful, the articles is really nice : D. Just right process, cheers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s