@schilling.mark.a/software-methodology 1.0.0 → 1.0.1

package/docs/story-map/user-tasks/ACT-001-task-001.md

@@ -0,0 +1,45 @@
+# ACT-001-task-001: Create Business Model Canvas
+
+## Activity
+ACT-001: Define Business Value
+
+## User Task
+As a product team or business owner
+I want to map out the business model including customers, value, channels, and revenue
+So that I understand the complete business context before building features
+
+## Value Proposition Link
+- Pain relieved: Disconnect between what we built and what users needed; Unclear requirements
+- Gain created: Connect engineering practices to business outcomes; Trace code to business value
+
+## Acceptance Criteria
+- Nine building blocks populated: Customer Segments, Value Propositions, Channels, Customer Relationships, Revenue Streams, Key Resources, Key Activities, Key Partnerships, Cost Structure
+- Each segment in BMC has corresponding VPC
+- Ubiquitous language terms identified and documented
+- BMC file created at `/docs/business-model-canvas.md`
+- BMC follows format from `product-strategy/references/business-model-canvas.md`
+
+## Priority
+- **MoSCoW:** Should Have
+- **Business Value:** High
+- **Complexity:** Medium
+
+## Release
+Release 2 - Full Product Strategy
+
+## Dependencies
+- None (can be first or second artifact; VPC can standalone for single features)
+
+## Feature File
+`/features/product-strategy/business-model-canvas.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+BMC provides broader business context than VPC. VPC can exist standalone for feature-level work. Full product strategy includes both.

package/docs/story-map/user-tasks/ACT-001-task-002.md

@@ -0,0 +1,48 @@
+# ACT-001-task-002: Create Value Proposition Canvas
+
+## Activity
+ACT-001: Define Business Value
+
+## User Task
+As a developer or product team member
+I want to define customer jobs, pains, and gains and how the product addresses them
+So that all work traces back to real user needs and business value
+
+## Value Proposition Link
+- Pain relieved: Unclear or changing requirements lead to rework; Disconnect between "what we built" and "what users needed"
+- Gain created: Trace code back to business value; Deliver features users actually want and use
+
+## Acceptance Criteria
+- Customer profile identified with at least one segment
+- 3-5 customer jobs listed in order of importance
+- 3-5 pains listed with specific magnitude where possible
+- 3-5 gains listed that define success
+- Each pain has a pain reliever or documented disposition
+- Each gain has a gain creator or documented disposition
+- VPC file created at `/docs/value-proposition-canvas.md`
+- VPC follows format from `product-strategy/references/value-proposition-canvas.md`
+
+## Priority
+- **MoSCoW:** Must Have
+- **Business Value:** High
+- **Complexity:** Medium
+
+## Release
+Release 1 - Walking Skeleton
+
+## Dependencies
+- None (first artifact in methodology chain)
+
+## Feature File
+`/features/product-strategy/value-proposition-canvas.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+VPC is the foundation artifact. Every downstream skill reads from it. Quality here determines quality downstream.

package/docs/story-map/user-tasks/ACT-002-task-001.md

@@ -0,0 +1,47 @@
+# ACT-002-task-001: Create User Personas
+
+## Activity
+ACT-002: Understand User Needs
+
+## User Task
+As a product team member
+I want to document who our users are, their goals, frustrations, and context
+So that we design features for real people with real needs
+
+## Value Proposition Link
+- Pain relieved: Disconnect between built vs needed; No shared language
+- Gain created: Deliver features users actually want and use
+
+## Acceptance Criteria
+- 2-5 personas created, one per key user segment
+- Each persona includes: name, role, goals, frustrations, context, scenarios
+- Persona goals map to VPC gains
+- Persona frustrations map to VPC pains
+- Personas use specific details (not generic descriptions)
+- Personas saved in `/docs/personas/[name].md`
+- Personas follow format from `ux-research/references/personas.md`
+
+## Priority
+- **MoSCoW:** Should Have
+- **Business Value:** High
+- **Complexity:** Medium
+
+## Release
+Release 2 - UX Research Foundation
+
+## Dependencies
+- ACT-001-task-002: Create Value Proposition Canvas (source for goals and frustrations)
+
+## Feature File
+`/features/ux-research/personas.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Personas humanize the VPC customer segments. They make abstract "users" concrete and memorable.

package/docs/story-map/user-tasks/ACT-002-task-002.md

@@ -0,0 +1,47 @@
+# ACT-002-task-002: Map User Journeys
+
+## Activity
+ACT-002: Understand User Needs
+
+## User Task
+As a UX researcher or product designer
+I want to visualize the user's current journey including actions, thoughts, and emotions
+So that I can identify pain points and opportunities for improvement
+
+## Value Proposition Link
+- Pain relieved: Disconnect between what we built and what users needed
+- Gain created: Deliver features users actually want; Identify highest-value improvements
+
+## Acceptance Criteria
+- Journey map created for at least one key persona
+- Map includes: stages, actions, touchpoints, thoughts, emotions, pain points, opportunities
+- Pain points map to VPC pains
+- Opportunities map to potential gain creators
+- Journey saved in `/docs/user-journey-maps/[persona-name]-journey.md`
+- Journey follows format from `ux-research/references/journey-mapping.md`
+
+## Priority
+- **MoSCoW:** Should Have
+- **Business Value:** High
+- **Complexity:** High
+
+## Release
+Release 2 - UX Research Foundation
+
+## Dependencies
+- ACT-002-task-001: Create user personas (need persona to map their journey)
+- ACT-001-task-002: Create Value Proposition Canvas (source for pains)
+
+## Feature File
+`/features/ux-research/journey-mapping.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Journey maps reveal the context around user needs. They show where in the user's workflow pain occurs.

package/docs/story-map/user-tasks/ACT-002-task-003.md

@@ -0,0 +1,46 @@
+# ACT-002-task-003: Document Mental Models
+
+## Activity
+ACT-002: Understand User Needs
+
+## User Task
+As a UX researcher
+I want to understand how users currently think about and organize information in this domain
+So that I can design interfaces that match their existing mental models
+
+## Value Proposition Link
+- Pain relieved: Built features don't match what users expected
+- Gain created: Users can accomplish tasks efficiently without extensive training
+
+## Acceptance Criteria
+- Mental model diagram created showing user's conceptual structure
+- Model identifies key concepts and their relationships
+- Model shows what users expect to find grouped together
+- Model highlights mismatches between user expectations and current system
+- Model saved in `/docs/mental-models/[domain].md`
+- Model follows format from `ux-research/references/mental-models.md`
+
+## Priority
+- **MoSCoW:** Could Have
+- **Business Value:** Medium
+- **Complexity:** High
+
+## Release
+Release 3 - Advanced UX Research
+
+## Dependencies
+- ACT-002-task-001: Create user personas (need to understand who we're modeling)
+
+## Feature File
+`/features/ux-research/mental-models.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Mental models inform information architecture decisions. They prevent organizing features by technical structure when users think in different terms.

package/docs/story-map/user-tasks/ACT-003-task-001.md

@@ -0,0 +1,47 @@
+# ACT-003-task-001: Create Story Map Backbone
+
+## Activity
+ACT-003: Plan Features
+
+## User Task
+As a developer or product team member
+I want to organize user activities in a backbone derived from VPC customer jobs
+So that I can see the user's journey and plan features in the right sequence
+
+## Value Proposition Link
+- Pain relieved: Hard to know what to build first or how to prioritize
+- Gain created: Have clear criteria for "done" before starting; Ship smaller increments more frequently
+
+## Acceptance Criteria
+- Each VPC customer job maps to one user activity
+- Activities ordered by typical user flow (left-to-right)
+- Each activity has a user goal statement
+- Each activity links back to VPC pains and gains
+- Backbone file created at `/docs/story-map/backbone.md`
+- Backbone follows format from `story-mapping/references/backbone.md`
+- Activity count between 3-7 (not too granular, not too coarse)
+
+## Priority
+- **MoSCoW:** Must Have
+- **Business Value:** High
+- **Complexity:** Medium
+
+## Release
+Release 1 - Walking Skeleton
+
+## Dependencies
+- ACT-001-task-002: Create Value Proposition Canvas (source for customer jobs)
+
+## Feature File
+`/features/story-mapping/backbone.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Backbone is the horizontal spine that all tasks hang from. Changes here ripple through entire story map.

package/docs/story-map/user-tasks/ACT-003-task-002.md

@@ -0,0 +1,46 @@
+# ACT-003-task-002: Define Walking Skeleton
+
+## Activity
+ACT-003: Plan Features
+
+## User Task
+As a product team member
+I want to identify the thinnest end-to-end slice that proves the architecture works
+So that we validate the technical approach before adding depth
+
+## Value Proposition Link
+- Pain relieved: Hard to know what to build first
+- Gain created: Ship smaller increments more frequently; Reduce technical risk early
+
+## Acceptance Criteria
+- Walking skeleton includes one simplified task per activity
+- Each included task has explicit "Included" and "Excluded" behaviors
+- Walking skeleton delivers end-to-end value (not just technical demo)
+- Success criteria defined for skeleton completion
+- Walking skeleton saved in `/docs/story-map/walking-skeleton.md`
+- Follows format from `story-mapping/references/walking-skeleton.md`
+
+## Priority
+- **MoSCoW:** Should Have
+- **Business Value:** Medium
+- **Complexity:** Medium
+
+## Release
+Release 2 - Complete Story Mapping
+
+## Dependencies
+- ACT-003-task-001: Create story map backbone (need activities to slice through)
+
+## Feature File
+`/features/story-mapping/walking-skeleton.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Walking skeleton proves end-to-end value delivery with minimum implementation. It's the core of Release 1 scope.

package/docs/story-map/user-tasks/ACT-003-task-003.md

@@ -0,0 +1,49 @@
+# ACT-003-task-003: Plan Release 1
+
+## Activity
+ACT-003: Plan Features
+
+## User Task
+As a product owner or tech lead
+I want to define what goes into the first release and what gets deferred
+So that the team ships valuable functionality quickly and iterates based on feedback
+
+## Value Proposition Link
+- Pain relieved: Hard to know what to build first or how to prioritize
+- Gain created: Ship smaller increments more frequently; Deliver working software that users want
+
+## Acceptance Criteria
+- Release goal clearly stated (what end-to-end capability this delivers)
+- Tasks categorized using MoSCoW prioritization
+- Each Must Have task justified with VPC pain or gain
+- Release includes vertical slice across activities (not horizontal)
+- Success metrics defined
+- Risks identified with mitigations
+- Release plan saved in `/docs/story-map/releases/r1-[name].md`
+- Follows format from `story-mapping/references/release-planning.md`
+
+## Priority
+- **MoSCoW:** Must Have
+- **Business Value:** High
+- **Complexity:** Medium
+
+## Release
+Release 1 - Walking Skeleton
+
+## Dependencies
+- ACT-003-task-001: Create story map backbone (need tasks to prioritize)
+- ACT-003-task-002: Define walking skeleton (forms core of R1)
+
+## Feature File
+`/features/story-mapping/release-planning.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Release planning is a skill task that produces release plan artifact. Walking skeleton typically becomes R1 scope.

package/docs/story-map/user-tasks/ACT-003-task-004.md

@@ -0,0 +1,47 @@
+# ACT-003-task-004: Break Down Activities into Tasks
+
+## Activity
+ACT-003: Plan Features
+
+## User Task
+As a developer or product owner
+I want to decompose each user activity into specific implementable tasks
+So that the team can estimate, assign, and track progress on discrete work items
+
+## Value Proposition Link
+- Pain relieved: Hard to know what to build first; Unclear requirements
+- Gain created: Have clear criteria for "done"; Ship smaller increments
+
+## Acceptance Criteria
+- Each activity has 2-10 tasks identified
+- Each task follows template format (user story, acceptance criteria, priority, dependencies)
+- Tasks are right-sized: completable in 1-3 days
+- Each task produces 1 feature file with 2-5 scenarios
+- Tasks saved in `/docs/story-map/user-tasks/[ACT-ID]-task-[NNN].md`
+- Tasks follow format from `story-mapping/references/task-template.md`
+- Tasks ordered within each activity by dependency and value
+
+## Priority
+- **MoSCoW:** Must Have
+- **Business Value:** High
+- **Complexity:** Medium
+
+## Release
+Release 1 - Walking Skeleton
+
+## Dependencies
+- ACT-003-task-001: Create story map backbone (need activities to break down)
+
+## Feature File
+`/features/story-mapping/task-breakdown.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Task breakdown is where planning becomes actionable. Each task file becomes input to BDD specification.

package/docs/story-map/user-tasks/ACT-004-task-001.md

@@ -0,0 +1,48 @@
+# ACT-004-task-001: Run Example Mapping Session
+
+## Activity
+ACT-004: Specify Behavior
+
+## User Task
+As a developer, product owner, or domain expert
+I want to explore a user task using concrete examples before writing formal scenarios
+So that we discover edge cases and shared understanding efficiently
+
+## Value Proposition Link
+- Pain relieved: Unclear requirements lead to rework; No shared language between roles
+- Gain created: Have clear criteria for "done" before starting; Shared understanding across team
+
+## Acceptance Criteria
+- Example mapping session conducted with at least 2 roles (e.g., dev + PO)
+- User story written on yellow card
+- Rules captured on blue cards (acceptance criteria, business rules)
+- Examples captured on green cards (concrete scenarios)
+- Questions captured on red cards (unresolved issues)
+- Session output captured in task file or separate notes
+- Session takes 25 minutes or less per story
+- Follows approach from `bdd-specification/references/example-mapping.md`
+
+## Priority
+- **MoSCoW:** Should Have
+- **Business Value:** High
+- **Complexity:** Low
+
+## Release
+Release 2 - Full BDD Specification
+
+## Dependencies
+- ACT-003-task-004: Break down activities into tasks (need user story to explore)
+
+## Feature File
+`/features/bdd-specification/example-mapping.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Example mapping is the workshop that produces clarity before writing Gherkin. Walking skeleton skips this and writes scenarios directly.

package/docs/story-map/user-tasks/ACT-004-task-002.md

@@ -0,0 +1,49 @@
+# ACT-004-task-002: Write Gherkin Scenarios
+
+## Activity
+ACT-004: Specify Behavior
+
+## User Task
+As a developer
+I want to specify expected behavior using concrete examples in Gherkin format
+So that I have clear acceptance criteria before writing code
+
+## Value Proposition Link
+- Pain relieved: Unclear requirements lead to rework; No shared language between developers, product, and stakeholders
+- Gain created: Have clear criteria for "done" before starting; Establish shared understanding across all roles
+
+## Acceptance Criteria
+- Feature file created for one user task
+- 2-3 scenarios written in Given-When-Then format
+- Each scenario has descriptive name that explains the behavior
+- "So that" clause traces to a VPC gain
+- Scenarios use ubiquitous language from domain
+- Scenarios are executable (avoid vague assertions)
+- Feature file follows format from `bdd-specification/references/gherkin-patterns.md`
+- Feature file saved in `/features/` directory
+
+## Priority
+- **MoSCoW:** Must Have
+- **Business Value:** High
+- **Complexity:** Low
+
+## Release
+Release 1 - Walking Skeleton
+
+## Dependencies
+- ACT-003-task-001: Create story map backbone (source for user tasks)
+- ACT-001-task-002: Create Value Proposition Canvas (source for "So that" clauses)
+
+## Feature File
+`/features/bdd-specification/gherkin-scenarios.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Scenarios become acceptance tests in ATDD workflow. Quality here = quality of test coverage. Simplified version skips example mapping workshop and writes scenarios directly.

package/docs/story-map/user-tasks/ACT-004-task-003.md

@@ -0,0 +1,47 @@
+# ACT-004-task-003: Review Scenarios with Stakeholders
+
+## Activity
+ACT-004: Specify Behavior
+
+## User Task
+As a developer or business analyst
+I want to validate written scenarios with product owners and domain experts
+So that we catch misunderstandings before implementation starts
+
+## Value Proposition Link
+- Pain relieved: Unclear requirements lead to rework; No shared language between roles
+- Gain created: Reduce rework; Shared understanding; Fewer defects found in production
+
+## Acceptance Criteria
+- Scenarios reviewed with at least one stakeholder outside dev team
+- Stakeholder confirms scenarios match their understanding of requirements
+- Stakeholder validates "So that" clauses deliver actual business value
+- Terminology in scenarios uses ubiquitous language from domain
+- Ambiguities resolved and scenarios updated
+- Review feedback captured in scenario comments or task notes
+- Reviewed scenarios marked as "stakeholder approved"
+
+## Priority
+- **MoSCoW:** Should Have
+- **Business Value:** Medium
+- **Complexity:** Low
+
+## Release
+Release 2 - Full BDD Specification
+
+## Dependencies
+- ACT-004-task-002: Write Gherkin scenarios (need scenarios to review)
+
+## Feature File
+`/features/bdd-specification/scenario-review.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Scenario review is the quality gate that catches requirement misunderstandings early. Prevents building the wrong thing.

package/docs/story-map/user-tasks/ACT-005-task-001.md

@@ -0,0 +1,47 @@
+# ACT-005-task-001: Design Information Architecture
+
+## Activity
+ACT-005: Design User Experience
+
+## User Task
+As a UX designer or product designer
+I want to organize information and functionality in a structure that matches user mental models
+So that users can find what they need without confusion
+
+## Value Proposition Link
+- Pain relieved: Built features don't match what users expected
+- Gain created: Users can accomplish tasks efficiently; Reduced learning curve
+
+## Acceptance Criteria
+- Site map or app structure created showing main sections and hierarchy
+- Structure aligns with user mental models (from ux-research)
+- Navigation patterns defined (top nav, side nav, tabs, etc.)
+- Information grouped by user goals, not technical architecture
+- IA document saved in `/docs/information-architecture.md`
+- Follows guidance from `ux-design/references/information-architecture.md`
+
+## Priority
+- **MoSCoW:** Should Have
+- **Business Value:** High
+- **Complexity:** Medium
+
+## Release
+Release 3 - UI/UX Design
+
+## Dependencies
+- ACT-002-task-003: Document mental models (source for user structure expectations)
+- ACT-003-task-001: Create story map backbone (source for user activities)
+
+## Feature File
+`/features/ux-design/information-architecture.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+IA is foundation for UI design. It organizes functionality before visual design. Skip for non-UI features (APIs, CLIs).

package/docs/story-map/user-tasks/ACT-005-task-002.md

@@ -0,0 +1,48 @@
+# ACT-005-task-002: Create Screen Flows
+
+## Activity
+ACT-005: Design User Experience
+
+## User Task
+As a UX designer
+I want to map the sequence of screens users navigate to accomplish their tasks
+So that I verify the flow is logical and complete before building
+
+## Value Proposition Link
+- Pain relieved: Built features don't match what users expected; Users confused by interface
+- Gain created: Users can accomplish tasks efficiently without training
+
+## Acceptance Criteria
+- Screen flow diagram created for at least one key user journey
+- Each screen identified with purpose and key elements
+- Transitions between screens documented (buttons, links, actions)
+- Flow covers happy path and key error states
+- Flow reviewed against Gherkin scenarios for alignment
+- Screen flows saved in `/docs/screen-flows/[flow-name].md`
+- Follows format from `ui-design-workflow/references/screen-flows.md`
+
+## Priority
+- **MoSCoW:** Should Have
+- **Business Value:** Medium
+- **Complexity:** Medium
+
+## Release
+Release 3 - UI/UX Design
+
+## Dependencies
+- ACT-004-task-002: Write Gherkin scenarios (screen flow implements scenarios)
+- ACT-005-task-001: Design information architecture (flows navigate IA structure)
+
+## Feature File
+`/features/ui-design-workflow/screen-flows.feature`
+
+## Status
+- [x] Acceptance criteria defined
+- [ ] Example mapping complete
+- [ ] Scenarios written
+- [ ] Acceptance tests created
+- [ ] Implementation complete
+- [ ] Deployed
+
+## Notes
+Screen flows are the blueprint for UI implementation. They connect scenarios to actual screens.