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
Performance tracking: Three flags for missed due dates or tasks without assignees will affect your PR (Performance Review)
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
Performance tracking: Three flags for messy boards will affect your PR
If task due dates don't align with developer priorities, we undermine the entire priority system. Consistency is critical for effective coordination.
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
Performance tracking: Three flags for bad project visibility will affect your PR
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.
We can't have caos in the kitchen we need a clean kitchen. Keep your kitchens clean!
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
Our task format ensures consistency and clarity, leveraging PMs' combined organizational skills, project understanding, management acumen, and technical expertise to establish the optimal project structure.
Use Somara Assistant “Task Generator”
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:
Important Links: HF, LF, relevant Docs
Objective
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
Responsibles - PM creates tasks, Dev completes ACC, QA reviews ACC
QA Tasks
Use Somara Assistant “QA Task Generator”
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
Important: You must create separate tickets for each QA issue. One issue = one ticket with its own status. Don't combine multiple issues in the same thread - it creates confusion and makes tracking impossible.
Performance tracking: Three flags for messy boards where there are multiple issues in one ticket will affect your PR
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 (Optional but Recommended)
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)
Start from clear beginning point
Provide specific actions (clicks, entries, observations)
End with bug verification
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]
Responsibles - PM creates tasks, Dev completes ACC, QA reviews ACC
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.