Sprint Guideline

Description

Naming Concepts

• Epic: A block of tasks that are too complex to be delivered in a single sprint and are broken down into smaller, more manageable user stories, the epic provides the "why" and the overall objective.

• Milestones: are key events or checkpoints that mark a significant achievement or the completion of a major phase of work. They are not tasks themselves, but rather moments in time that show important progress has been made.

• Sprint: 10 weekdays (2 weeks), which will guide the team through constant iterations

Plutio Tabs

Client Board (Only client, PM, and PE can view)

1. Assets (Here, we are going to include the refinement assets - when applicable - and client assets)

2. To Do

3. Done

Developer (All can view)

1. Backlog (All tasks for the app)

2. To Do (Tasks for this sprint) 

3. Doing (Tasks in progress)

4. Review (Tasks pending review from QA)

5. QA (Tasks that were not approved by QA because of some bug or missing feature required on the ACs)

6. Done (Finished tasks)

7. Epic (Tasks that encompass a list of other tasks)

Calls & Timeline (All can view)

1. Phase & Timeline

   1. Refinement Phase

   2. Design Phase

   3. Development Phase

   4. Warranty Period

2. Calls - This can be used for tracking all the conversations and used to add a summary of what happened

   1. Kick-off & Refinement 01

   2. Refinement #

   3. LF #

   4. HF #

   5. Sprint Check-In # (Client)

3. Internal Meetings - All the internal meetings, dev, design, or sync internal
   

   1. Sprint Planning

   2. Sprint Review

   3. Internal Call
      
      

Internal (Only team members can view)

1. Backlog Tasks

2. Customer Success

   1. NPS #

3. Client

   1. Invite Client To Plutio

   2. Invite Client To Slack

   3. Research Integration #

4. Internal
   

   1. Create a bot to trigger the dev check-in (to discuss)

   2. Review Scope & Refinement Assets

   3. Fill Roadmap Spreadsheet

   4. Sprint Backlog

   5. Sprint Evaluation

Design (Only PM and Designer can view)

1. Low Fidelity

2. High Fidelity

Developer Capacity

Ceremonies

Sprint Backlog

Sprint Planning

Important Notes

QA Handling

• QA tasks should always be completed by whoever created the original task

• Exception: When a dev leaves the project, their QA work must be reassigned

• If QA can't be completed in the sprint, it goes to backlog and may be addressed in a later sprint depending on priority

• Bugs unrelated to current sprint work go to backlog unless they're blocking critical flows

Buffer & Timeline Management

• It’s a good practice to maintain a buffer time in sprints for adjustments

• Focuses on completing priority work first, then uses remaining capacity for adjustments/backlog

• Part-time devs are brought in when needed based on project assessment

PM Responsibility

1. Present Ready Backlog Items: The PM presents the backlog items that have already been refined and are ready to be worked on, guiding the team during the session.

2. Update Backlog Fields: Once the team has agreed on the work and provided estimates, the PM is responsible for updating the backlog tool with the final information, including Dev hours/points, Epic, and the chosen Sprint.

3. Sprint Evaluation: PM should complete sprint evaluation after each sprint (https://forms.lowcode.agency/WthZ1w)

4. Task Prioritization: The PM facilitates the team discussion to organize tasks in priority order during planning meetings.

Dev Responsibility

1. Estimation and Commitment: The developers collectively estimate the effort for each task. Their commitment to the work is based on this shared understanding.

2. Decomposing Large Stories: The team uses a collaborative guideline, such as the 6-point limit, to identify stories that are too complex or risky. When a story exceeds this limit, it is a signal for Project Manager to break it down into smaller, more manageable tasks.

3. Estimation Confirmation: Devs should take around half a day after planning to review and confirm point estimations before starting work. This prevents surprises when tasks turn out more complex than initially estimated.

Points Management

• Assignment: During the meeting, go through each dev individually, assigning tasks until reaching 24 points per sprint.

• Part-Time Devs: The maximum points for a part-time developer should be determined on a case-by-case basis (e.g., proportional to their availability compared to the full-time max of 24 points).

• Tracking: Points are tracked in the "Dev hours points" field in Pluto

Task Prioritization

• Tasks are prioritized by placement order in the sprint - whatever is on top is the priority

• During planning meetings, the team discusses and organizes tasks in priority order together

• Dependencies are handled through discussion rather than formal dependency tracking in Plutio

Dev Check-In

• Duration: < 60 minutes (it depends on the team size and the project complexity)

• Participants: Tech Lead and Devs

Sprint Standup (As-sync Daily Check-in)

Sprint Review & Retrospective 

• Duration: 30 minutes to 1 hour (it depends on the project size and complexity) (I think we should put 1h duration only, if someone can make in less great) 

• Participants: PM, Devs, and QA

• Success metric:

  • Goal: 100% of all tasks done and approved

  • Acceptable: 80% or more of all tasks done and approved

  • Failure: Less than 80% of all tasks done and approved

Part 1 - Check-In

• Check for pending work on To-Do, Doing, Review, QA, and check with the devs if what is pending can be finished on the current sprint (5 min)

Part 2 - Sprint Review

The first segment of the meeting is dedicated to the Sprint Review. The focus is on the product, and key activities include:

• Incomplete Work: All incomplete work goes to the backlog and is reprioritized. Only sprint-critical/blocking items are forced into the next sprint.

• An informal round-up of completed stories and Product Backlog Items: Quickly demonstrate what is "Done" and show its value. (Suggested time 5 min)

• Sprint Goal Recap: Remind everyone of the sprint's objective. (Suggested time 2 min)

• PM Acceptance & Feedback: The PM confirms the work meets requirements and provides feedback. (Suggested 10 min)

Part 3 - Sprint Retrospective

The second segment of the meeting is dedicated to the Sprint Retrospective. The focus is on the process, and key activities include:

• Gather insights 

  • What Went Well (Suggested Time: 3 min)

  • What Went Wrong (Suggested Time: 3 min)

  • Things We Can Improve (Suggested Time: 3 min)

  • Action Items (Suggested Time: 10 min) - Create 1-2 concrete, actionable, and owned improvements about the "HOW" things are made

• Meeting wrap-up: Summarize the action items and thank the team. This is fundamental to solidifying the agreements. (Suggested time 4 min)

• Review key metrics: Analyze performance data. (Future version)