Task Creation Standards

For Project Managers, Business Analysts, and Quality Assurance

General Rules for ALL Tasks

1. Assignment & Due Dates

• No tasks without an assignee AND due date (exceptions: backlog/sprint definition tasks only)
• Due dates must be accurate and realistic
  
  • Due dates must match priorities
  • We need reliable data for resource planning and coordination

2. Daily Board Management

• Tasks must be in the correct column at the start of each day (keep them clean on the daily)
• PMs must review ALL active projects daily, regardless of notifications (you may have 0 notifications for a project but you should still actively review it.)
  • Exception: Completed projects that no longer require daily review
• Keep boards clean and organized - this is a core PM competency

3. Leadership Visibility Requirements

Ceci and Jesus must have instant access to project status by just taking a look at Plutio:

• WHO is doing WHAT
• WHEN will it be READY

4. Project Handover Standard

Plutio must be so clear and organized that anyone can take over your projects immediately. This way you can go on vacation easily without having to much work for someone to watch over your projects or if for any reason someone needs to take over transition is seamless. Think of this like developers maintaining clean databases for seamless handover.

Milestones/V1 Development Tasks

1. Pre-Definition Requirements

• Tasks must be fully defined and clear by/for PM before assignment to developers
• All V1 tasks require acceptance criteria added by PM/BA or Trainee
• Follow the standardized format below ⭐

2. Methodology-Specific Due Dates

• Glide Projects: All V1 tasks share the same due date ( 🌈 Waterfall methodology)
• Bubble Projects: Tasks separated into sprints with unique colors and staggered due dates ( 📶 Agile-ish methodology)
• Alternative methodologies: Since each project is so unique some projects may require some process adaptation, if this is ever the case flag with leadership before implementation

3. To-Do Column Standard

No tasks in developer's To-Do column without clear acceptance criteria checklist

4. ⭐ V1 Milestone Task Format

1. Task Naming

Tasks should follow this established template:   (Sprint) [Role] | [Screen, Functionality, Flow or Integration]

Examples:

• S1 - US  | Phyllo Integration
• S2 - SA  | Education Resources Details
• US | Profile Details > Edit Profile Button

2. Task Description

Each task description must include:

• User Story: As a (Role), I want to (action) so that I can (outcome).

• Acceptance Criteria Checklist (ACC):

      Book a Call Button

           Redirect to Calendly

            Show multiple events in one day with their name

       User can join/register events of Super Admins

• Resources:

  • LF -
  • HF -
  • Relevant Doc(s) -

QA Tasks

1. Naming Convention

Format: QA - [Role] > [Screen] > [Issue] ([Type])

Example: QA - SA > Sign Up Screen > Can't reset password (BLOCKER)

Issue Types: BLOCKER, UI/UX, FIX, BUG

2. QA Task Description Template

Description

• User Role: [Specify the user type experiencing the issue]
• Screen/Location: [Where the issue occurs]
• Issue Summary: Brief, clear explanation focusing on the problem (not the solution)
• Keep it concise: 1-3 sentences typically

Expected Behavior

• Describe correct functionality
• Be specific about expected user experience
• Use bullet points for clarity
• Avoid technical implementation details unless necessary

Actual Behavior

• Factual, objective description of current behavior
• Use bullet points for distinct issues
• Include error messages when applicable
• Video documentation strongly preferred

Reproduction Steps (Optional but Recommended)

1. Start from clear beginning point
2. Provide specific actions (clicks, entries, observations)
3. End with bug verification
4. Keep steps logical and concise

3. QA Workflow Requirements

• Assignment: QA tasks assigned to developer with 1-2 day due date
• Speed is critical: Fast QA cycles prevent bugs from compounding
• Daily cycle: QA tickets created and resolved daily once QA phase begins
• Smooth transitions: RFR (Internal) → QA → RFR (Internal) → Completed
• One issue per task: Each QA ticket should be separate (minor fixes may be combined)

4. Documentation Best Practices

• Video recordings: Try to include ALWAYS
• Attach to task: Videos should be directly linked and easily visible for devs

New Scopes - Task Based

1. Naming Convention -  [Role] | [Screen, Functionality, Flow or Integration]

• Same as v1 tasks

2. Scope Clarity Requirements

• One milestone per flow/feature/screen/integration (unless app requires different approach)
• Multi-role flows: Acceptance criteria must highlight visibility conditions and role-specific changes

3. Temaplate

Client Request Example

"I want Users to be able to book a call through Calendly and it should be automated meaning once they book it automatically shows on their calendar."

Expected Outcome/Short Description

Users will book calls through Calendly with automatic calendar integration.

User Story Format

As a [Role] I want to [action] so that I can [outcome]

Acceptance Criteria Template

• Book a Call Button functionality
• Calendly redirect process
• Multiple daily events display with names
• User registration/joining for Super Admin events

Design Requirements

• Includes Design
• Doesn't include Design

Technical Considerations

Calendly integration must automatically add booked events to user's personal calendar (Google Calendar, Outlook, etc.) without manual intervention. Implementation requires Calendly API or built-in automation features.

Resources

• Wireframes: N/A
• Documentation: https://docs.google.com/[link]

This document serves as the foundation for consistent, professional task management across all projects. Adherence to these standards is essential for project success and team coordination.