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 problems – Problems in writing proper user stories – What a Scrum User story is not meant to be – Part 2

The previous article (Scrum stories being too generic) was about providing the required right level of detail in Scrum User Stories, in order to make it represent the User Workflow. In this article, we focus on what a User Story should not be, and though these may seem obvious when we think about these deeply, these are mistakes that are often enough made during the course of a Scrum implementation and be one of the causes that contribute to the failures of Scrum implementations.
So, in this post, let us talk about what a Scrum story should not be.
– First and foremost, no cutting of corners. A User Story needs to have a Product Owner involved. I have seen cases where the Product Owner was a busy person, and was spread thin over the various teams. As a result, the Product Owner would be involved in the drafting of the User Stories, but then would leave it to the ScrumMaster or some other senior members of the team. This is a recipe that has lead to a number of failures, since getting somebody else to interpret the User Stories and explain those to the team can and does lead to a miscommunication (which becomes clear only when the team is near the demo, or when they have already spent some time on the work). The problem is, this happens in a minority of the User Cases, such that it may not cause a problem in the first Sprint Cycle, but may start showing up in later Sprint cycles, or when there is more complicated work involved.
– For somebody who reads the words ‘User Story’, there is a strong temptation to treat these as a smaller version of Use Cases. These are 2 different concepts, instead focus on what a User Story should contain in terms of the user needed workflow, allowing easy testing and completion criterion, and being capable of delivered in one Sprint.
– Stories are not meant to be a detailed specification. You are not going back to the time of the Waterfall model where you have to deliver a User Story that crosses all the dots of the need, and then make it difficult during the implementation to modify the actual implementation as per the best fitment (for example, you could specify the entire and detailed workflow in the User Story), but then that is no longer the User Story as told from the User point of view, it instead becomes a proxy for the design document. A user story is supposed to be short, essentially setting the ground for more communication as the work progresses. One easy way in which this can be enforced is by writing a user story on a small index card (3 inch X 5 inch), thus forcing you to be short and sweet.

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>