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 problems – Problems in writing proper user stories – getting too generic, or getting into too much detail – Part 1

User Stories are a very important part of Scrum, since User Stories are essentially the requirements part of the Scrum process. User Stories are used by the Product Owner to explain the requirements to the Scrum team, and need to be at a level where they can be used to test against, the QE team can determine that the User Story has been met, and does not indicate the type of technology that needs to be used. However, it is in these areas that a User Story can fail, and set the Scrum team on a path where they spend too much effort or build something that is different from what the Product Owner really wanted. How can these events happen ? Let us consider 2 examples of Scrum User Stories. The case is about designing the Login System for a Bank, where the appropriate security level has to be set.

Example 1:
The User Story goes like this: “Design a security system with an appropriate level of security”

Example 2:
The User Story goes like this: “Use a XYZ application to build a Login system that will provide 256 bit security levels and will ensure support for Browser A, B and C. It will deny access to other Browsers, and be built in the PHP coding language”

If you compare both these User Stories, they are both on an extreme. The User Story pitted in Example 1 does not provide any level of detail, and is very vague. It does not describe the user experience, and could be translated to actually just refer to the controls present on the page (and the Scrum team will have to a lot of back and forth with the Product Owner to get more details).
The User Story mentioned in Example 2 is very detailed, and implies details that are more of implementation details, to be part of the design considerations. In the end, the system may be build exactly as it is detailed, but it is for the design team to decide the appropriate level of security, the language to be used, and the User Story does not present the situation from the User point of view.
If one were to write a User Story that works for the scrum team, then the temptation to get into too many technical details needs to be avoided. The User story needs to be written from the user perspective, explaining the actions that a user is likely to take (including the many possible variations, wrong inputs, etc) and the return values and data provided by the system back to the user. Take care that the User Stories do not get into technical details, and instead focus on the points mentioned above, such that you are getting into writing effective User Stories.

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>