What define a good User Stories?
written by gunther gerlach-2009
If we go back to the basics, I would define User Stories as a simple tool of communication to capture user requirements throughout a project based on the business requirements and stake holder’s needs. This is a perfect, easy and fast alternative to writing extensive requirements specifications to start developing. While the technical issues and integration problems are hard to find with a simple overview of the business or technical requirements, the user Histories give some time a better overview of the details by a simple and descriptive walk, step by step by every process.
Note: This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why.
An easy way to construct User Stories is answering the following questions:
As a [user role], I want to [goal], so I can [reason].
Besides capturing “small” User Stories in the above format on the Product Backlog, User Stories should be written on a card. This is a normal activity to better understand how this process works.
Card composition:
Card [what I just described]
Dialog [Notes about the feature]
Confirmation [a test that show when the feature is complete].
Process:
When User Stories are complete, they should be entered on the Product Backlog, to later define the releases. The final goal of the User Stories is finding the balance between the written and verbal requirements, filling the gaps and minimizing misunderstanding; improving collaboration between team’s members, clarifying details.
Heart of User Stories:
· Independent. Okay, for some systems, it’s near impossible to make each feature completely independent. In other solutions, e.g. web sites, it’s easier. But it’s an important aspiration. User Stories should be as independent as possible.
· Negotiable. User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.
· Valuable. User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
· Estimatable. User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.
· Small. User Stories should be small. Not too small. But not too big.
· Testable. User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.
few steps to make User Stories Perfect
Make them customer-focused. The easiest way to do this is to have the customer write them. If this isn’t practical, then you’ll have to role-play. An example of a developer-focused story is “Add clustered index to the Orders table.” This doesn’t mean much to most customers, and a real customer (unless they are a DBA), would probably never write this. Instead, something like “Improve Order reporting performance”, captures the same information, but is understandable to everyone on the team.
Make them elevator-friendly. A good story should be something you could explain on an elevator in 30 seconds or so to a team member. Don’t write a novel. Remember, this is just a placeholder for more detailed conversations, not a specification or requirements document.
Make them the right size. Not too big, and not too small, just like Goldilocks said when she visited a tough bear hangout. For me, the right size is usually under 40 ideal hours (1 ideal week) of estimated effort. Small stories aren’t usually a problem, but if they get to be under an hour or so, you probably want to batch them up. Defects are usually good candidates for batching into a single story, as long as they are small and easy to implement.
Make them testable. An untestable story might be something like “Make the order screen easy to use.” It sounds nice, but no one really knows what this means, or how to objectively verify it. A better wording choice might be: “A novice user be able to load, enter information, and submit an order within 5 minutes.” Hmmm…still seems a little questionable, but I can probably write a test like “Given a sample group of 10, 8 of these users should be able to complete an order for a book in 5 minutes.”.
