The Catalpa Handbook
  • The Catalpa Handbook
    • Handbook guidelines
  • 1. ABOUT CATALPA
    • 1.1 About Catalpa
    • 1.2 Vision, Values and Strategic Plan 2022
    • 1.3 Governance at Catalpa
    • 1.4 Organisational structure of Catalpa
    • 1.5 Our projects and key contacts for each
    • 1.6 Our key products
      • Bero
        • Content
          • Exams
          • Targeting Content to Users
            • Resizing images for Bero
        • Design
        • Requirements
        • Theming
      • Gathr
      • Openly
  • 2. OUR PEOPLE AND HOW WE WORK
    • 2.1 How we work and the tools we use
      • Google Drive
      • Trello
      • Github
      • InVision
    • 2.2 Communicating internally
      • All Hands Stand-up (weekly / Mondays)
      • Tutorial Tuesdays
      • Show & Tell
      • Guide to Slack
      • Team meetings
      • Other Events
    • 2.3 Mission Driven Teams
    • 2.4 Recruitment and Onboarding
      • Hiring Guidelines
    • 2.5 How we support our people to thrive
      • Onboarding a new hire
        • Onboarding Trello
        • Onboarding buddy guide
        • 30/60/90 Day Plan
      • Goal Setting
      • Regular work/task based 1X1's
      • Quarterly Catch Up's
      • Feedback
      • Managers - Managing Underperformance
    • 2.6 Offboarding
    • 2.7 Leave and public holidays
      • Leave
      • Public Holidays
    • 2.8 Supporting our Mental Health
    • 2.9 Working from home & remotely
    • 3.0. Learning & Development Allowance
  • Page
  • 3. EXTERNAL COMMUNICATIONS
    • 3.1 Guide to Communication
      • Describing Catalpa
      • Guide to photography
      • Guide to social media
      • Writing: style guide
      • Writing: grammar
    • 3.2 Procedures for the collection, storage and use of stories, photos and video
    • 3.3 External Complaints and Feedback Policy
  • 4. PARTNERSHIP AND GROWTH INCLUDING BUSINESS DEVELOPMENT
    • 4.1 Introduction / overview
    • 4.2 Pre-bid stage including networking and partnering
      • Networking
      • Positioning for priority bids
      • Tracking bid opportunities
      • Partnering
        • Partnership brokering
        • Due diligence of downstream partners /subcontracting agencies
        • Pre-bid agreements
    • 4.3 Go / No Go
      • Go / No Go meetings
      • Selection criteria and guidelines
    • 4.4 Tender planning and preparation
      • Project planning and design pre-submission
      • Key templates and links for bid planning and preparation
      • Bid Writing - full proposal or concept note
        • How to appoint an external bid writer
        • Key templates
        • Commonly required building blocks / required materials for tenders
        • Guides
    • 4.5 After a bid has been submitted
  • 5. PROJECT AND PRODUCT CYCLE MANAGEMENT
    • 5.1 Introduction
    • 5.2 Planning and pre-submission design
      • 5.2.1 Monitoring, Evaluation & Learning
        • Project-level M&E
        • Catalpa's organisational approach to MEL
      • 5.2.2 Risk Management
      • 5.2.3 Cross-cutting issues in projects
        • Gender equality
        • Disability inclusion
    • 5.3 Mobilising a new project
      • Handover from BD team to PM team
      • Program Summary Document
      • Team Kickoff Meeting
      • Team Charter
    • 5.4 Post-contract implementation
      • Stage 1 - Learn: Design and Discovery
        • Human Centred Design
        • Our Tools
        • Creating a product
      • Stage 2: Create and Ideate
        • Our model
        • Agile Project Management
          • Getting started
          • Product design and development phases
            • 0. Contracting
            • 1. Learn
              • 1.1. Prepare
              • 1.2. Discovery
              • 1.3 Empathise
            • 2. Create
              • 2.1 Ideate
              • 2.2 Implement
            • 3. Refine
            • 4. Evaluate
          • Product Roadmap
          • Defining releases
          • Create the solution
          • Make a global plan
          • User Stories
          • Prototyping
          • Incremental development
          • UX & UI
          • Conducting tests
      • Stage 3: Refine and Release
        • Introduction and overview
        • Data privacy on a project basis
        • How-tos
          • Retrospective
        • Scrum methodology
          • Daily standup
          • Sprints
          • Sprint prep
          • Sprint meeting
        • Release
          • Epics
          • Epic selection
          • Epic planning
          • Product Q&A, deployment and implementation
          • Make it available
          • Delivery
      • Stage 4: Evaluate
        • Define the maintenance support plan and team
        • Customer support
        • Ongoing user data collection and analysis
      • Glossary of Terms
    • 5.5 Project close-out
      • Product transition and handover
      • Transition to governmen
      • SMA
      • Licenses / handover documents
      • Migrating to Gov owned data-center or cloud hosting
  • 6. POLICIES AND PROCEDURES
    • 6.1 Register of policies and compliance
    • 6.2 Policy Development Procedure
    • 6.3 Code of Conduct
    • 6.4 Data Privacy & Storage Policy
    • 6.5 Human Resources Policies
      • Breastfeeding and Work Policy
      • Occupational Health and Safety Policy
      • Domestic and Family Violence Policy
      • Gender Equality Policy
      • Disability & Discrimination Policy
      • Use of Catalpa Vehicles Policy - PNG
      • Anti-Bullying, Harassment and Discrimination Policy
    • 6.6 Safeguarding Policies, Templates and Training
      • Child Safeguarding Policy
      • Prevention of Sexual Exploitation, Assault and Harassment Policy (PSEAH)
      • Safeguarding templates
      • Safeguarding training
      • Safeguarding procedure for collecting, storing and using images / stories
    • 6.7 Financial and Asset Management
      • Fraud & Corruption Policy
      • Vehicle Use
    • 6.8 Complaints and Feedback
      • Internal Complaints and Feedback Policy
      • External Complaints and Feedback Policy
      • Whistleblower Policy
    • 6.9 Contract Development Procedure
Powered by GitBook
On this page
  • Epic selection
  • Epic planning
  • Epic design document
  • Epic planning meeting

Was this helpful?

  1. 5. PROJECT AND PRODUCT CYCLE MANAGEMENT
  2. 5.4 Post-contract implementation
  3. Stage 3: Refine and Release
  4. Release

Epics

An epic is a large body of work that can be broken down into a number of smaller stories.

PreviousReleaseNextEpic selection

Last updated 11 months ago

Was this helpful?

An agile epic is a body of work that can be broken down into specific tasks (called ) based on the needs/requests of our partners.

Epics are a helpful way to organize your work and to create a hierarchy. The idea is to break work down into deliverable pieces, so that large projects can actually get done and you can continue to ship value to your customers on a regular basis. Epics help teams break their work down, while continuing to work towards a bigger goal.

Maintaining agility when organizing large tasks, like epics, is no small task. Learning how epics relate to a healthy agile program is an essential skill no matter the size of your organization.

Epic selection

We build our products incrementally. This means that you'll focus on one Epic at a time, delivering it before starting the next one. To do this, the team gets together for an Epic Selection meeting during which they will agree on what is the best sequence to deliver the Epics. By the end, everyone should have a clear idea of how these Epics will line up in time and why.

Check the guide

Check the template on

Epic planning

Check the guide

Epic design document

You now know what the first Epic will be and are ready to start. At this point, the Team Leader will start a new Epic Design Document containing all the information needed to build this piece of functionality and to keep the entire team on the loop, allowing design and engineering to get started.

You can find a template for this document . It's important that you really nail it on two very important sections: the opening Summary that provides context, and the User Story list that represents all of the intended functionality.

For the Summary, it's important to clarify what problem are we trying to solve and how. It should also be clear what the approach will be and why we believe that our solution is a good answer.

The User Stories are an Agile way of conveying functional requirements in a way that the whole team is able to grasp. There are a number of advices on how to create a good User Story but the secret is to make them easy for everyone to understand, making sure the objectives are clearly written and that they are small enough in complexity so that they can be delivered within days rather than weeks.

Your document can also include a third part where the team can make note of important concepts and outstanding questions. As work moves forward, this section works as documentation for future reference.

Epic planning meeting

Once the document has enough detail, it's time for the Team Leader to present it to the team in an Epic Planning meeting. During this meeting, the team has the opportunity to ask for clarifications, to help sorting priorities and dependencies, as well as rating User Stories according to their complexity. One of the fundamental rules for the Epic Planning meeting is to have it some time prior to the work is due to be started. This way we can learn from the team's feedback and use the available time to integrate changes, investigate solutions and pursue answers. The main purpose is to get everyone on the same page and making sure the goals are understood by the whole team.

After the meeting, all the User Stories are ready to be added to Github and associated to a new Milestone that represents the Epic.

Check the template on Some notable examples can be found and

User Stories
Epic selection
Catalpa's Drive
Epic planning
on the Drive
Catalpa's Drive
here
here