Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum basics: How to write user stories, one of the most critical components of Scrum

When people talk about requirements during the course of gathering requirements for a project, they would normally talk about mapping the business requirements in a way that these can be broken down into design concepts and then into further details in terms of code and test cases (the whole traceability matrix). However, the whole task of getting the requirements down into a list that can be used to generate a product that meets these can be complex. The need to have somebody who can understand the requirements and then write these into a way that the development team can use is a difficult one, and there are a large number of cases where the requirements are too business like, written in a way that the development team finds it difficult to break down into design (or the scope of mis-interpreting the business requirements can be fairly significant). In the case of Scrum, the effort to ensure that these requirements need to be in a way that the team can easily understand and then develop leads us to the concept of User Stories.
So what are User Stories ? The User Stories are an attempt to explain the business requirement in a way that mimic the interaction between users and the product, with the main focus being to show what the user gets from the product, what value the system adds to the user. User Stories are primarily written from the User point of view, and does not get into the regular level of detail that the requirements documentation would get into, are more light weight, and most importantly, need to be specified just before when the team starts to get into doing that work (which means that the User Story for a work that is being done 3 months into the project need not be defined at the beginning of the project, but 3 months later).
However, with the User Story being more simpler, there are some attributes that these User Stories need to have:
– The Value: The User Story should be able to clearly define what value they bring to the customer (there are a few exceptions, such as when we need to define tasks that are needed for architectural work, or specific tasks that related to incorporation of newer versions of components, but even those need to be folded into some User Story)
– Estimation: Since the Sprint team depends on these User Stories for defining the tasks that they need to do, the User Stories should be defined such that estimation based on them is possible.
– Small: The User Stories should be such that tasks based on these User Stories should not be long (which means that if you write detailed User Stories that take 2 weeks to complete, then re-think this; a User Story should not take more than a week at the maximum, most tasks should be just a few days)
– Conducive to test: When User Stories are defined, they should be easily testable, such that the team can easily define when the User Story is completed.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>