Hug a developer – genius! Awesome work from Devshop…

A not so quick video (sorry I blab to much) about how I implement an Agile Wall at my place of work. Even if you have done a wall before – besure to at least check out the second half of the video for a few tricks and tips that I do with different colors and sized binders.

Last week I wrote how writing user stories is easy – today I want to talk about another way to ensure your user stories are written well – the INVEST model.

The acronym is INVEST which stands for:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Let’s look at each one in detail…

Independent

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.

Negotiable

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.

Estimable

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.

Small

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.

Testable

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!