I'm not sure I agree totally with Hugh. I think the real issue is that Lean is misunderstood by many in IT. Lean emphasizes defining value and quality from the perspective of the customer. It's certainly about "faster and cheaper" but it was devised within a larger context.
When you study the Toyota Production System from which Lean is based (and the writings of Ford & Deming which is what much of TPS is based on), you realize that it has always been true that defining the "what" was as important as streamlining production, or the "how". Just look up "Genchi Genbutsu" and read how the engineers at Toyota apply this to product design, not just streamlining manufacturing.
Dean, I think the real issue you face in defining done is about having enough data to clarify your goals and focus the tasks. The tasks you list are just as important as development tasks, but they are product owner and UX tasks. They are about creating a good product backlog. The challenge is most of the Agile literature assumes you have a product owner that knows what to build, or easy access to users like in an IT project. When building products, especially new ones, those are often false assumptions, hence why UX methods were invented.
Hugh is absolutely correct that if you make up stories based on hypothetical assumptions about users it won't matter how fast or efficient you are as you build your product or service, as you'll be wasting a lot of time building the wrong stuff. Not very lean...
@innes_jon on Twitter
On Aug 28, 2011, at 8:44 AM, HRB wrote:
--- In firstname.lastname@example.org, "Dean Morrow" <dmorrow6@...> wrote:
> I've been thinking for some time about how to leverage lean principles
> from a UX /product development perspective. I'm finding some facets of
> UX/Prod Dev work… especially those around early stage
> discovery/research/analysis… aren't lending themselves to standard
> agile methods and tools...
> Discovery stories are more about learning and less about doing. My
> current project is a website restructuring/redesign. Instead of stories
> like "As a shopper, I want to add an item to my cart" I have something
> like "I want to get visibility into what are the biggest problems on the
> site" or "I want to know what is on the site" or "I want to know who
> uses the site most" or "I want to understand what users can do on the
> site." Tasks end up things like "meet with business unit X to understand
> their goals and what they do" or "review the existing style guide." How
> do you define done in a learning context?
> Dean Morrow
I congratulate you on your creativity, but this has very much the flavor of a square peg being pounded into a round hole. Lean techniques came from lean *manufacturing* -- making a known product faster with less expense. That's pretty much the antithesis of creativity, invention, design, or anything else UX people have to worry about.
I'd find a process appropriate for learning about your user community and inventing solutions for them. I wouldn't expect that process to have much to do with Lean (or even classic Agile, come to that). If you come to the point of writing stories and you don't at that point already understand your user and the proposed solution, you're in trouble.