How To INVEST In Your User StoriesFiled Under Software Process
The acronym is INVEST which stands for:
Let’s look at each one in detail…
Stories need to be able to stand by themselves and not be dependent on the assumption that a particular amount of work has been accomplished by another unfinished story. This also provides us the ability to schedule or remove any single story (in any order) without affecting other stories.
Sometimes stories do overlap (and that’s ok), but creating atomic units of work is very important to the Agile/User Story concept.
I love this explanation:
A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories. -Will Wake
As a I have said before – user stories are not features; rather, it is a summary of scenario that will end up being accomplished by both the customer and programmer.
If a story is too large (or is not understood enough) to be estimated, then the scenario is not understood enough to prioritize or develop.
Smaller units of work tend to receive smaller and more accurate estimations. Having user stories that are estimated at weeks or even months is a complete guess and implies that we do not understand the problem at all.
User stories are meant to be at the level of granularity such that they can be completed within an iteration (if not a single day). My preference is have user stories broken down so every developer can accomplish at least one user story a day.
If you don’t understand how or what to test, then either that is an indicator that you don’t fully understand the problem or that the conceived solution is incorrect. In some cases, it is the test scenarios that will produce what the user story looks like.
I have created a simple page sized poster you can print out and hang on your wall as a reminder – download. Good luck!