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.
|