User Stories

The structure of the User Story for the modules is:

I want to [do something] so that I can [derive a benefit]

This is the way to stay curious and at the same time stay organized about how we gather that understanding, encapsulate it, and share it with the rest of our team.

They need to be INVEST: Independet Negotiable Valuable Estimable Small Testable

Independent: Could this be implemented on a stand-alone basis or does it prepuppose other content? Negotiable: Stories are not spec's. This is an input for you to arrive at an optimal implementation with the developer, not a functional 'requirement'. Valuable: What problem scenario does this address? How have you validated your value proposition for it? Estimable: How hard is this vs. the team's experience? Is it discrete enough? That's important because if they're not, they're probably also not small enough. Small: A big part of what makes agile (and lean) work is the use of small batches with measurable results. Make sure your stories are broken down to workable sizes. It's important that we're able to work in these small batches where we're able to implement something in software, and then go make observations about whether it's valuable, or whether we need to retread it in some fashion. Testable: How you know if it's working in a way where you can validate its value? How do we test it to see if the user is getting these sources of value out of it, especially on a very preliminary basis. So could we make a mock-up and create a scenario where we could do some simple user testing early?