1. Journey design, sharing, review #PM
Design the journey of the core target, which is the initial concept, and draw the flow from the moment they enter the service-to-be-built to final delivery.
2. Set epic guidance, share, review #PM
Separate epics by stakeholder, and each epic should be self-contained. Self-contained here means the epic, on its own, delivers a meaningful unit of usability that lets the user do what they set out to do.
*After release, though, epics are set by watching KPIs through funnel analysis. #PO
3. Execution (one sprint unit, 1/4) — #service planning
Write the user stories the epic contains, along with acceptance criteria, then share and update through review.
*Depends on context, but this was written on the basis that 'one epic' = 'one sprint.'
**After release, though, set 'one story' = 'one sprint.'
3. Execution (one sprint unit, 2/4) #product design
Design the GUI for each story, then share and update through review.
3. Execution (one sprint unit, 3/4) #development
Walk the prototype and file issues. Once all issues are resolved, do dev design, then build, then demo.
4. Demo and retro (one sprint unit, 4/4) #everyone
Run usability tests at each unit. After the retro, decide whether to release or drop.
Design the journey of the core target, which is the initial concept, and draw the flow from entry into the service-to-be-built to final delivery.
5. Misconceptions
Both agile and lean startup grow from an MVP outward, in components (or module-shaped features). Those components are released or added via internal retro or beta testing.
What the TF has to keep in mind: a planner is not a leader but someone who represents users and consumers (a non-leader persuading the internal TF naturally makes data a key tool). A designer must bring not only styling but especially planning power (useful something, not pretty trash). A developer must realize they are producing not LEGO / puzzle-piece / magnet pieces that snap together with perfect efficiency, but button-, bolt-nut-, or male-female-ring-shaped pieces (which include spatial overlap losses in the process of connecting).
The common rule: hold ownership, but do not fall into attachment. Even components dropped during a specific sprint should not simply be discarded — keep them at a reusable state (backed up as valid assets).
