Finding our Moon
Every project begins with clarity of purpose. That clarity lives in the Product Requirement Document (PRD).
PRD (Artefact)
Purpose: Details the project’s main Objectives and Outcomes.
Contents:
- Summary: What we’re doing & why (max 5 lines)
- Customers & their Problem
- Outcome Goals & KPIs (with measurable targets)
- Scope (MVP) & Non-Goals
- Top Requirements
- Risks & Mitigations
- Rollout & Measure
- Owners & Dates
From the PRD, the Product Backlog is created — the ever-evolving list of work that moves us toward the vision.
Client Discovery Document (Artefact)
Purpose: Captures essential insights about the client — their personality, motivations, goals, and communication preferences — to guide collaboration and ensure the team works in harmony with the client throughout the project.
Contents: Client personality type (using the Red, Blue, Yellow, Green Framework): Identifies the client’s working and communication style to tailor collaboration approaches effectively.
- Client motivations and drivers: Outlines what inspires and drives the client — whether it’s speed, quality, innovation, or collaboration — to align delivery with their priorities.
- Goals for this product and desired outcomes: Defines the objectives the client wants to achieve with the product and the measurable results they expect.
- Key dates and milestones important to the client: Captures critical deadlines, events, or checkpoints that must be respected throughout the project lifecycle.
- Notable points, preferences, or considerations mentioned in meetings: Records specific requests, working preferences, sensitivities, or contextual insights shared by the client that may impact delivery.
Storage & Maintenance: Stored in Confluence and treated as a living document.
Updated continuously as the relationship evolves and new insights emerge.
Product Backlog (Artefact)
Purpose: Continuously prioritised, clarified, and refined by the Product Owner.
Structure:
- Epics → broken down into Product Backlog Items (PBIs)
- PBIs are either User Stories, Tasks, or Bugs.
Product Backlog Items (PBIs)
User Stories: Written from the persona’s perspective.
- As a [X], I want to [Y], so I can [Z]
- Must include Acceptance Criteria & Design Reference
- Owned by Product Owner, completed before the first Devign Inspiration session (min. 2 sprints ahead)
Tasks: Non-functional items (e.g. deploy environment, configure payment gateway).
Bugs: Use a clear format:
- Expected Behaviour: [X]
- Actual Behaviour: [Y]
Inspiration and Refinement
With a backlog in place, the team begins preparing work for sprints. This happens in Devign Inspiration.
Devign Inspiration Workshop (Event)
Time Box: 90 minutes
Frequency: Every Month
Owner: Product Owner
Attendees: Devign Master, Product Owner, Developers, Designer
Purpose: Aligns the team on upcoming work, refines stories, explores innovation, and estimates effort.
This workshop isn’t just a backlog grooming exercise—it’s our space to push boundaries and innovate. The goal is not only to understand what we’re building but to ask why we’re building it and what else might be possible. This is the team’s opportunity to bring their best thinking to the table, challenge assumptions, and collectively discover better paths forward.
Must-haves before the session:
Prioritised Epics and User Stories
Draft requirements and acceptance criteria
Quick market scan / research notes on existing tools, frameworks, or approaches that might apply (prepared by Developers or Designers before the session)
How it runs:
- Presentation & Clarification
- Product Owner presents backlog items.
- Developers and Designers ask clarifying questions to ensure shared understanding.
2. Exploration & Innovation (Tabula R.A.S.A)
- Pause to ask: Is there a better way?
- Explore alternatives and emerging technologies.
- Encourage everyone to bring one idea, however small, that could improve the outcome.
- Apply the Rapid Adaptation / Swift Adoption lens: what can we test quickly, and what could we adopt fast if it works?
3. Technical Discussion
- Define architecture, risks, dependencies.
- Split/refine large or vague stories.
4. Documentation
- Record session notes in Confluence (Project X → Devign Inspiration).
- Update/refine PBIs in Jira.
Why it matters:
The Devign Inspiration Workshop ensures we’re not just executing a backlog but actively shaping it. By carving out space for innovation every sprint, we balance delivery with discovery—keeping the product alive, relevant, and forward-thinking.
The output of this session feeds directly into the Sprint Backlog.
Sprint Backlog (Artefact)
Purpose: Contains the work selected for the sprint.
Requirements:
- Must include a Sprint Outcome.
- At least 2 sprints worth of work mapped ahead.
Sprint Outcome (Artefact)
Purpose: Guides the sprint, focusing the team on outcome rather than output.
Key Principles:
- Created during Sprint Planning.
- Describes value/result, not just tasks.
- Realistic, achievable, and unifying.
- Serves as a decision filter: Does this still help us meet our Sprint Outcome?
Committing to the Sprint
Once work is refined, the team meets for Sprint Planning.
Sprint Planning (Event)
Time Box: 45 minutes
Frequency: Every Sprint
Owner: Devign Master
Attendees: Devign Master, Product Owner, Developers, Designer
Purpose: Defines what will be done and how it will be achieved.
How it runs:
- Define Sprint Outcome
- Product Owner proposes priorities.
- Team aligns outcome with Product Outcome.
2. Select & Plan Work
- Team commits to PBIs from the top of the backlog.
3. Documentation
- Sprint Outcome + Sprint Backlog recorded in Confluence (Project X → Sprint Planning).
Executing the Sprint
Now the rhythm of the sprint begins, powered by one event that maintains alignment and accountability.
Daily Standup (Event)
Time Box: 15 minutes
Frequency: Every day
Owner: Devign Master
Attendees: Devign Master, Product Owner, Developers, Designer
Purpose: Surface blockers and keep momentum.
How it runs:
What was completed since yesterday?
What is being tackled today?
What’s blocking progress?
Follow-up: Actions noted in Confluence (Project X → Sprint XXXX) and Slack summary shared.
Reviewing the Work
As the sprint closes, focus shifts to ensuring quality and sharing results.
Sprint Go / No Go (Event)
Time Box: 1 hour
Frequency: Every Sprint
Owner: All Moonward
Attendees: All Moonward
Purpose: Internal checkpoint before client demo.
How it runs:
Was there a Sprint Outcome, and was it achieved?
Confirm deployment to QA/Staging.
Review demo against Moonward standards.
Validate completion in plan/outcome.
Stakeholders vote Go/No Go (any “No” stops the demo).
Approval marks sprint as complete.
Sprint Review (Client Demo) (Event)
Time Box: 1 hour
Frequency: Every Sprint
Owner: Product Owner
Attendees: Product Owner, Developers, Designer, Client
Purpose: Showcase the Product Increment and gather feedback.
Must-haves:
Demo from QA environment.
Work deployed & verified day before.
How it runs:
Team ready 5 mins early.
Welcome & introductions.
Product Owner revisits Sprint Outcome.
Developers demo functionality.
Stakeholders ask questions.
Product Owner shares backlog/roadmap updates.
Feedback & adjustments gathered.
Notes documented in Confluence (Project X → Sprint Review).
Product Increment (Artefact)
Purpose: The actual deliverable — code, design, or solution.
Definition of Done:
- Shared understanding of completion.
- Items not meeting DoD are not released.
- Failed items returned to backlog, marked QA Blocked.
Devign Update (Event)
Time Box: 30 minutes
Frequency: Every Sprint
Owner: Product Owner
Attendees: Product Owner, Designers, Client
Purpose: Quick touchpoint for transparency, roadblock escalation, and alignment on priorities.
How it runs:
Team ready 5 mins early.
Welcome & introductions.
Product Owner shares progress.
Highlight challenges.
Designer delivery is reviewed and prioritised to provide the development team with work for upcoming sprints.
Document in Confluence (Project X → Sprint Review).
Learning and Improving
The cycle ends not with delivery, but with reflection.
Sprint Retrospective (Event)
Time Box: 45 minutes
Frequency: Every Sprint
Owner: Devign Master
Attendees: Devign Master, Product Owner, Developers, Designer
Purpose: Learn from the past sprint and commit to improvement.
How it runs:
Welcome & introductions.
Gather insights (Continue, Stop, Start).
Identify root causes.
Brainstorm solutions.
Select one actionable experiment.
Summarise actions.
Document in Confluence (Project X → Retro).
The Cycle Restarts
With insights captured and improvements chosen, the team returns to Devign Inspiration - refining the backlog once more, carrying forward lessons learned, and recommitting to the vision.
Over time, these artefacts and events build not just products, but momentum. A rhythm of adaptation, delivery, and learning - the Devign Methodology in motion.