Rendered from the original file. Use Open in New Tab for the download.
Forming
| Team Goal: Deliver a stable campus-events MVP with a reliable event creation flow, resolve critical defects effectively, and meet the two-week demo deadline without compromising quality. |
|---|
| Group Members | Roles | Responsibilites | Influence | Priorities |
| YARA FARIS FAIHAN ALBUGAMI | Project Manager | All issues related to software project, chase and collect the status of project tasks. Also coordinate and create a plan | Formal | 1. Planning
2. Scheduling
3. Coordinating
4. Achieve project goals |
| HATOON ABDULLAH | Tech Lead | Technical architecture, technical risks, technical decisions, and supporting developers | Expert | 1. Assess the technical requirements and risks of the event creation flow.
2. Define the technical approach and architecture so developers can implement consistently.
3. Identify potential technical issues early and support the team in resolving them. |
| JUMANAH SALEH A ALBAZAI | Product owner | Protecting product value, defining scope and managing SH expectations | Value | Enforcing boundaries, defining product value |
| ROSE SAEED RAKAN AL RAKAN | QA Lead | I need to test the main features, report and prioritize bugs, and verify that fixes work before the product is released. | Expert | 1. Test the critical features of the app
2. Identify and prioritize bugs
3. Verify bug fixes |
| SHOUG FAWAZ ABDULLAH ALOMRAN | Developer | Implement assigned software features, write and maintain code, fix bugs, perform unit testing, and collaborate with the Tech Lead and QA Lead to ensure the software meets project requirements. | Expert | 1. Implement assigned features
2. Write clean and functional code
3. Fix identified bugs
4. Complete unit testing
5. Meet development deadlines and technical requirements |
Skills Matrix
| Skill Matrix | Yara | Hatoon | Jumanah | Rose | Shoug |
|---|
| Stakeholder management | High | Low | High | Low | Low |
| Technical architecture | High | High | Low | Low | High |
| Quality Assurance (defect isolation) | Moderate | Moderate | Moderate | High | Moderate |
| Prioritization | High | High | High | High | Moderate |
| Project Planning & Scheduling | High | Moderate | Moderate | Low | Low |
| Product/Scope Management | High | Moderate | High | Moderate | Low |
| Debugging & Implementation | Low | High | Low | Moderate | High |
| Testing & Validation | Moderate | Moderate | Moderate | High | High |
| Communication & Collaboration | High | High | High | High | High |
Performing - RACI
| Performing - RACI |
|---|
| Task | Yara PM | Hatoon Tech Lead | Jumanah PO | Rose QA | Shoug Developer |
| Confirm regression | C | A | I | R | R |
| Assess technical options | C | A/R | C | C | C |
| Decide recovery approach | C | A/R | C | C | C |
| Perform rollback | I | A | I | C | R |
| Verify restored system | I | C | I | A/R | C |
| Investigate root cause | I | A/R | I | C | R |
| Implement permanent fix | I | A | I | C | R |
| Test permanent fix | I | C | I | A/R | C |
| Communicate project status | A/R | C | C | I | I |
Storming
| Storming |
|---|
| RACI | Yara | Hatoon | Jumanah | Rose | Shoug |
| Evaluate change | R | R | C | C | C |
| Decide whether to prioritize | C | C | A/R | C | I |
| Assess technical impact | I | A/R | C | C | C |
| Assess testing impact | I | C | C | A/R | C |
| Communicate final decision | A/R | I | C | I | I |
| Member | Responsibility | | | | |
| Yara — PM | Lead the discussion and assess schedule/resource impact | | | | |
| Hatoon — Tech Lead | Assess technical feasibility, dependencies, effort, and technical risk | | | | |
| Jumanah — PO | Evaluate product value and decide whether the change should be prioritized | | | | |
| Rose — QA Lead | Assess testing impact and additional quality risks | | | | |
| Shoug — Developer | Estimate implementation effort and identify development dependencies | | | | |
| Team Decision | The requested feature will not automatically be added to the current sprint. The team will first evaluate its product value, technical effort, testing impact, and effect on the MVP deadline. If the change creates significant risk to the two-week deadline, it will be deferred to the next sprint. | We reviewed the requested demo feature against our current sprint commitments. Before adding it, we will assess its technical, testing, and schedule impact. If implementing the change puts the MVP deadline or quality at risk, we will defer it to the next sprint and keep the current MVP scope focused on the committed deliverables. | | | |
Norming
| Norming |
|---|
| | Vulnerability Round | |
| Member | Skill I Contribute | Area Where I Need Support |
| Yara — PM | Planning, coordination, and communication | Technical information when technical risks affect the schedule |
| Hatoon — Tech Lead | Architecture, technical problem-solving, and technical decision-making | QA/developer support when investigating complex defects |
| Jumanah — PO | Product prioritization and stakeholder management | Technical estimates and constraints from the development team |
| Rose — QA Lead | Testing, defect isolation, and quality assurance | Developer support when reproducing complex technical issues |
| Shoug — Developer | Implementation, debugging, and unit testing | Technical guidance when architecture or implementation decisions are unclear |
| Five Team Norms | Column 1 | |
| Norm 1 — Respectful conflict | We discuss disagreements openly and respectfully, focusing on the problem rather than the person. | |
| Norm 2 — Evidence-based decisions | Technical and project decisions should be supported by requirements, data, testing results, or reasonable estimates. | |
| Norm 3 — Early communication | Team members must communicate blockers and risks as soon as they are identified. | |
| Norm 4 — Commitment discipline | No team member should commit to work without considering available time, dependencies, quality, and the sprint deadline. | |
| Norm 5 — Support and accountability | Team members ask for help when needed, support each other, and take responsibility for their commitments and mistakes. | |
Team Norms and Trust Building
| Team Norm | Description |
|---|
| 1.0 | Respectful Communication: Discuss disagreements respectfully and focus on the problem, not the person. |
| 2.0 | Early Issue Reporting: Report blockers, risks, and critical defects immediately. |
| 3.0 | Regular Check-in: Hold short daily check-ins and keep task progress updated. |
| 4.0 | Controlled Scope Changes: Evaluate scope changes for technical, quality, and schedule impact before committing to them. |
| 5.0 | Individual Accountability: Complete assigned tasks on time and communicate early if a commitment is at risk. |
Performing 5-Step Implementatio
| Step | Action |
|---|
| 1.0 | Confirm the regression and identify the affected event-creation flow. |
| 2.0 | Roll back to the last stable version. |
| 3.0 | Verify that event creation is functioning correctly after the rollback. |
| 4.0 | Investigate the root cause and implement the permanent fix. |
| 5.0 | Test the permanent fix before redeployment. |
Performing Technical Crisis
| Item | Details |
|---|
| Root Problem | A critical regression in the event creation flow is affecting 30% of users. The root cause is unclear, and the team disagrees on whether to roll back or implement a hotfix. |
| Solution 1 | Roll back to the last stable version while investigating the root cause. |
| Solution 2 | Develop and deploy a hotfix for the current version. |
| Solution 3 | Temporarily disable the affected functionality while investigating and preparing a permanent fix. |
| Chosen Solution | Roll back to the last stable version to restore functionality, then investigate the root cause and develop a permanent fix. |
Accountability Next 48 Hours
| Member | Commitment | Deadline |
|---|
| Yara – PM | Track recovery progress, coordinate the team, and communicate project status. | Within 48 hours |
| Hatoon – Tech Lead | Lead root-cause analysis and review the permanent technical fix. | Within 24 hours |
| Jumanah – Product Owner | Confirm MVP priorities and ensure scope remains focused on the demo. | Within 24 hours |
| Rose – QA Lead | Perform regression testing and validate the permanent fix. | Within 48 hours |
| Shoug – Developer | Investigate the regression, implement the permanent fix, and support testing. | Within 36 hours |
Accountability Success Metrics
| Metric | Target |
|---|
| Event Creation Reliability | Event creation works successfully for 100% of tested user cases. |
| Critical Regression Testing | 100% of critical create, edit, and list test cases pass before redeployment. |
Retrospective Card
| Question | Answer |
|---|
| What went well? | Clear roles and RACI responsibilities helped the team respond quickly and coordinate the recovery. |
| What blocked us? | The root cause was initially unclear, and disagreement over rollback versus hotfix delayed the decision. |
| One improvement | Define incident-response and rollback criteria before the next sprint so critical defects can be handled faster. |
Debrief
| Debrief Question | Answer |
|---|
| Which Tuckman stage did you notice most strongly and why? | Storming was most noticeable because the team had to manage disagreement over changing the sprint scope and later decide between rollback and hotfix during the regression. |
| Where did trust help or hinder decision-making? | Trust helped members rely on each other's expertise, such as the Tech Lead for technical impact and QA Lead for testing impact. |
| Which conflict technique did the team use and what was the outcome? | The team used collaborative problem solving by evaluating product value, technical effort, testing impact, and schedule risk before making decisions. |
| How did RACI and the Skills Matrix affect decisions? | They clarified who had responsibility, accountability, and relevant expertise, reducing confusion and helping tasks reach the appropriate team member faster. |
| Did leadership type influence the choice? How would you change the leader approach? | Both technical and adaptive leadership were needed. Technical leadership supported defect resolution, while adaptive leadership helped manage disagreement, uncertainty, and stakeholder expectations. |
| What single improvement will you implement next sprint? | Establish clear incident-response and scope-change criteria at the start of the sprint. |