Skip to content

Commit 85132fa

Browse files
hcaballero2hcaballero2
authored
Merge pull request #192 from oss-slu/feature/issue-176-analyze-tech-lead-feedback
Analyze tech lead feedback and create mapping matrix
2 parents 5958d41 + 829ae63 commit 85132fa

3 files changed

Lines changed: 195 additions & 0 deletions

File tree

‎docs/User_Feedback_Form.md‎

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
# Feedback Forms
2+
3+
## OSS Dashboard General Feedback Form
4+
5+
We are working on improving the OSS Dashboard and would love to hear any feedback you may have.
6+
7+
### Questions
8+
1. How are you using the dashboard?
9+
- Tech Lead
10+
- Contributor
11+
- Just exploring
12+
- Other
13+
2. What do you like about the dashboard so far?
14+
3. Is there anything that is confusing or frustrating when you are using the dashboard?
15+
4. Are there any features or types of data you would like us to add?
16+
5. How often would you realistically use this dashboard?
17+
- Daily
18+
- Weekly
19+
- Occasionally
20+
- Probably would not use it
21+
6. Optional: If you are open to us following up with you, please leave your email below.
22+
23+
24+
25+
## OSS Dashboard Tech Lead Insights Form
26+
27+
We are working on improving the OSS Dashboard to better support tech leads. This form is meant to help us understand what metrics you care about and what would actually be useful for your team.
28+
29+
### Questions
30+
1. Name
31+
2. Project/Team Name
32+
3. What is your role (Tech Lead, Co-Lead, etc.)?
33+
4. What metrics do you usually track?
34+
- Velocity: Work completed per sprint
35+
- WIP (Work in Progress): How much work is active at once
36+
- Code Coverage: Percentage of code covered by tests
37+
- Defect Rate: Bugs discovered per sprint or per feature
38+
- Goal Achievement: Sprint goals met vs. planned
39+
- Burndown: Progress toward sprint completion over time
40+
- Team Satisfaction: How the team feels about their work and collaboration
41+
- Blocked Work: Tasks waiting on dependencies or decisions
42+
- Customer Satisfaction: Client feedback and sentiment
43+
- Time to Market: How long features take from idea to deployment
44+
- Other:
45+
5. What are the top 2-3 metrics that matter the most to you and why?
46+
6. If a metric is low (for example, sprint goals are not met), what do you usually do? Please make your answer as detailed as possible.
47+
7. What resources would you want the dashboard to show automatically?
48+
- Contribution guidelines
49+
- Onboarding docs
50+
- GitHub repo links
51+
- Slack/Discord channel
52+
- Example workflows/best practices
53+
- Other:
54+
8. Are there any specific links you would like us to include (docs, repos, guides, etc.)
55+
9. What would make this dashboard actually useful as a tech lead? Please make your answer as detailed as possible.
56+
10. What kinds of decisions would you want this dashboard to help with? Please make your answer as detailed as possible.

‎docs/mapping_matrix.json‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
{
2+
"velocity_low": {
3+
"actions": [
4+
"reduce scope",
5+
"break tasks into smaller parts",
6+
"remove blockers"
7+
],
8+
"resources": [
9+
"sprint planning documents",
10+
"github issues"
11+
]
12+
},
13+
"goal_achievement_low": {
14+
"actions": [
15+
"re-evaluate the sprint",
16+
"clarify requirements",
17+
"adjust workload"
18+
],
19+
"resources": [
20+
"sprint tracking documentation"
21+
]
22+
},
23+
"blocked_work_high": {
24+
"actions": [
25+
"identify dependencies",
26+
"escalate blockers",
27+
"check in with the team"
28+
],
29+
"resources": [
30+
"slack or discord",
31+
"github issues"
32+
]
33+
},
34+
"wip_high": {
35+
"actions": [
36+
"limit active tasks",
37+
"focus on completing work before starting new tasks"
38+
],
39+
"resources": [
40+
"agile workflow guides"
41+
]
42+
},
43+
"defect_rate_high": {
44+
"actions": [
45+
"improve testing",
46+
"prioritize bug fixes"
47+
],
48+
"resources": [
49+
"testing documentation",
50+
"ci/cd pipelines"
51+
]
52+
},
53+
"team_satisfaction_low": {
54+
"actions": [
55+
"check in with team members",
56+
"adjust workload",
57+
"improve communication"
58+
],
59+
"resources": [
60+
"team guidelines",
61+
"communication channels"
62+
]
63+
},
64+
"customer_satisfaction_low": {
65+
"actions": [
66+
"review deliverables",
67+
"prioritize fixes",
68+
"gather feedback"
69+
],
70+
"resources": [
71+
"client feedback tools",
72+
"project documentation"
73+
]
74+
}
75+
}

‎docs/tech_lead_analysis.md‎

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
## Overview
2+
I collected and reviewed 17 responses from the Tech Lead Insights Google Form. The goal was to identify which metrics they actually value, how they react when those metrics are not meeting their expectations, and what resources could help them take action. In general, most of the responses focused on delivery, team health, and removing blockers. A key takeaway was that tech leads are not just interested in numbers, but they also want insights that genuinely help them understand what is going wrong and what steps to take next.
3+
4+
## Key Metrics
5+
After reading the responses, the key metrics that kept coming up were:
6+
- Velocity
7+
- Goal Achievement
8+
- Blocked Work
9+
- Team Satisfaction
10+
- Work in Progress (WIP)
11+
- Defect Rate
12+
- Customer Satisfaction
13+
14+
Overall, these metrics provide a solid overview of how the team is performing and how the project is going as a whole.
15+
16+
## What Tech Leads Do When Metrics Are Low
17+
From checking out the responses, one thing that really stood out is that tech leads do not treat low metrics as failures, they view them as indicators that something is off.
18+
19+
In most cases, they follow this process:
20+
1. They start by trying to identify the root cause, like whether there are any blockers, too much workload, or tasks that are not clear.
21+
2. Next, they reach out to the team, whether it's through meetings, on Slack, or through one-on-ones.
22+
3. Then, they often adjust the workflow by scaling back the scope, reordering tasks, and redistributing the workload, and they concentrate on getting rid of any blockers or enhancing the process.
23+
24+
This shows that the dashboard should not just point out problems, but also assist tech leads in figuring out the next steps they should take.
25+
26+
## Requested Resources
27+
Many tech leads shared that they would want the dashboard to provide easy access to:
28+
- GitHub repository links
29+
- Onboarding docs
30+
- Contribution guidelines
31+
- Slack/Discord channels
32+
- Example workflows/best practices
33+
34+
## Key Insights
35+
Several key points emerged from the feedback. Tech leads are looking for more than just data, they want insights that can actually help them take action. They also care a lot more about trends over time instead of just a single moment of time.
36+
37+
It was clear that the dashboard needs to highlight specific risks and obstacles early on, instead of waiting until the issues arise. Having everything in one place is crucial since it saves time and prevents the hassle of toggling between different tools. Overall, the ability to quickly take action, such as accessing links or resources right away, is a top priority.
38+
39+
## Mapping Matrix
40+
This mapping allows the dashboard to trigger specific actions and resources whenever a metric dips below a set threshold.
41+
42+
Based on the feedback, I created a simple mapping matrix that connects low metrics to typical actions taken by tech leads and the resources that would help.
43+
44+
1. If velocity is low:
45+
- Actions: Reduce scope, break tasks into smaller parts, and eliminate any obstacles.
46+
- Resources: Sprint planning documents and GitHub issues
47+
2. If goal achievement is lacking:
48+
- Actions: Re-evaluate the sprint, make the requirements more clear, and adjust the workload
49+
- Resources: Sprint tracking documentation
50+
3. If there is a large amount of blocked work:
51+
- Actions: Identify dependencies, escalate blockers, and check in with the team
52+
- Resources: Slack/Discord, GitHub issues
53+
4. If Work in Progress (WIP) is high:
54+
- Actions: Limit the number of active tasks and focus on completing work before working on something new
55+
- Resources: Agile workflow guides
56+
5. If defect rate is high:
57+
- Actions: Enhance testing and prioritize bug fixes
58+
- Resources: CI/CD pipelines
59+
6. If team satisfaction is low:
60+
- Actions: Check in with team members through one-on-ones, adjust workloads, and improve communication
61+
- Resources: Team guidelines and communication channels
62+
7. If customer satisfaction is low:
63+
- Actions: Review deliverables, prioritize fixes, and gather more feedback
64+
- Resources: Tools for client feedback and project documentation

0 commit comments

Comments
 (0)