1. Lean UX Approach
1.1. Every business problem has many possible solutions
1.2. The challenge is figuring out which solutions are viable and then, of the viable ones, the most valuable
1.3. Assumption: our initial product designs will be wrong
1.3.1. In most cases, it's impossible to predict the right solution in advance
1.3.2. "People will tell you what they want when you have given them what they asked for"
1.4. Process
1.4.1. 1. Treat each design as a hypothesis — a proposed business solution
1.4.1.1. what is the smallest, simplest, cheapest, fastest thing you can build to test the hypothesis?
1.4.1.1.1. This is your MVP
1.4.1.2. Focus on the highest risk and uncertainty, then highest value
1.4.2. 2. Validate the hypothesis as quickly as possible
1.4.2.1. Seek customer/user feedback against a working system/prototype
1.4.3. 3. Adapt design and plan according to feedback and learnings
1.4.3.1. You collect what you learn from your MVP, develop your ideas and adapt invalid assumptions
1.4.4. 4. Rinse and repeat
1.4.4.1. Then you do it again
2. Work breakdown Strategies
2.1. Two of my favourites:
2.1.1. Work backwards from end result and build the minimum needed to achieve result
2.1.2. Happy path
2.2. Counter-culture:
2.2.1. YAGNI
2.2.2. Requires aggressive refactoring
2.2.2.1. => automated regression testing
2.3. https://medium.com/@chrisverwijs/10-powerful-strategies-for-breaking-down-user-stories-in-scrum-with-cheatsheet-2cd9aae7d0eb
2.4. Mike Cohn SPIDR
2.4.1. poster
3. Structure/Terminology
3.1. Partner
3.1.1. [1..*] Project
3.1.1.1. [1..*] MVP
3.1.1.1.1. [1..*] Epic
3.1.1.2. [0..*] Bug
3.1.1.3. [0..*] Improvement
3.1.1.4. [0..*] Service Request
3.1.1.5. [0..*] Risk
3.2. By definition, User Story is the smallest unit of delivery
4. We need to balance 2 forces that are in tension
4.1. User Story delivers an end-to-end customer outcome
4.1.1. not split according to functional areas such as design, development, test, deploy
4.1.2. not split according to technical layers, such as front-end, business logic, back-end
4.1.3. Why end-to-end?
4.1.3.1. Deliverables are meaningful and usable by customer
4.1.3.2. Easier to prioritise
4.1.3.2.1. can ask the customer
4.1.3.3. Exposes risks of end-to-end delivery
4.1.3.3.1. addresses watermelon releases
4.1.4. Challenge:
4.1.4.1. it's goes against the intuitions of most engineers
4.1.4.1.1. batching work is a more efficient use of a developers/testers time
4.2. User Story is small enough to be deliverable in one Iteration/Sprint
4.2.1. Why "small batch size" REALLY matters?
4.2.1.1. small (+ focus) means faster
4.2.1.1.1. faster means
4.2.1.2. small means
4.2.1.2.1. problems are localised
4.2.1.2.2. more likely to deliver to Iteration/Sprint timeboxes
4.2.1.2.3. we are better able to shed the lemons
4.2.2. Challenge:
4.2.2.1. How then do we come up with thinly sliced user stories?
5. 3 Assertions
5.1. It's important to find the right "batch size" for delivery
5.1.1. smaller is almost always better
5.1.2. Waterfall is "Everything"
5.1.3. Agile is "As small as viable"
5.2. Progress (of project work) is best defined in terms of customer outcomes delivered rather than tasks completed
5.2.1. and those outcomes should be treated as binary
5.2.1.1. i.e., either they are fully complete or they are not
5.2.1.2. there is no 'nearly'
5.3. The speed at which we learn is #1 thing slowing us down
5.3.1. Thought experiment:
5.3.1.1. If at the end of a project, you “started again”: How long would it take you?
5.3.1.2. Studies show 1/4 to 1/2 time
5.3.1.3. Hence our biggest constraint is speed of learning
5.3.2. Unfortunately at the start of the project, we know the least...
6. Subject
6.1. Work breakdown
6.1.1. What?
6.1.1.1. iterative activity of dividing a complex system into smaller more manageable pieces
6.1.2. Why?
6.1.2.1. improve understanding of the problem/solution spaces
6.1.2.1.1. details
6.1.2.1.2. dependencies
6.1.2.1.3. risks
6.1.2.1.4. constraints
6.1.2.1.5. Question: How do you slay a dragon?
6.1.2.2. improve accuracy of estimation of the amount of effort needed to create a solution
6.1.2.2.1. time
6.1.2.2.2. cost
6.1.2.3. allow traceability
6.1.2.3.1. be able to define meaningful progress
6.1.3. How?
6.1.3.1. involves the identification and capture of User Stories needed to deliver the scope of work (+ friends)
6.2. Why am I talking about this subject?
6.2.1. My experiences suggest that good work breakdown practices are one of the best indicators for group performance
6.2.1.1. and it's a critical for an agile way of working
6.2.2. Also, several groups are already working on weekly Iteration/Sprint cadences
6.2.2.1. so it's critical to be able to break work down well
6.2.2.2. I would like to continue this idea with other groups if it works for our experimentees