Create a project retrospective meeting agenda

작성자: AILesson8 분 소요검토일: 2026-08-29

빠른 답변

Review observable outcomes, process conditions, and improvement experiments without assigning blame. 제공할 내용: Project baseline and outcomes, Participants and context, Retrospective scope. 예상 결과: A psychologically safer retrospective agenda with evidence prompts and bounded experiments.

맥락 추가

텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.

Project baseline and outcomesParticipants and contextRetrospective scope

프롬프트

채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다

Create a project retrospective meeting agenda grounded in observable evidence.

Objectives, plan, actual outcomes, timeline, incidents, changes, and evidence:
[baseline]

Participants, power differences, confidentiality, conflict, accessibility, and facilitator:
[team]

Duration, scope, data, authority, decision limits, and follow-up:
[scope]

Separate outcomes, observations, interpretations, and proposed causes. Review system conditions and decision points without inferring intent or turning the meeting into individual performance evaluation. Offer equal input routes and a way to raise sensitive issues outside the group. Prioritize no more improvement experiments than the supplied capacity supports; each needs hypothesis, owner only if confirmed, evidence, duration, and review trigger. Return pre-work, timed agenda, evidence questions, facilitation safeguards, experiment template, parking lot, and follow-up review.

Playground에서 사용해 보기

기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.

입력에서 결과까지

적용 예시

구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요

실제 입력

Project baseline and outcomes: Website migration planned 6 weeks, completed in 8. Forty pages moved; five had broken links at launch, fixed next day. Plan assumed content approval by week 2; 11 pages arrived in week 4. Two unplanned accessibility fixes added 3 days. No evidence identifying a single cause of the full delay.
Participants and context: Product, content, engineering and accessibility representatives; engineering manager attends with two engineers. Product Ops facilitates. Anonymous pre-input available. Individual performance is out of scope.
Retrospective scope: 60 minutes. Data: plan, issue log, approval dates, launch checks. Team can approve at most two process experiments for next release. Sensitive staffing issues route to managers separately. Review experiments after four weeks.

예시 출력

Pre-work: timeline with planned/actual dates; issue log; approval dates; launch-check evidence. Participants label each note Observation, Interpretation, or Proposal; anonymous route remains open.

Agenda (60 minutes) 0–6 access, confidentiality, no-blame and no-performance boundary. 6–14 restate objective and recorded outcomes: 40 pages, eight weeks, five launch link issues fixed next day. 14–26 timeline review: content approvals, accessibility additions, dependencies. Ask 'What changed, when, and according to which record?' Do not ask who caused the delay. 26–36 patterns that helped or hindered; separate evidence from hypotheses. 36–46 generate process experiments silently first, then round-robin; staffing concerns route outside. 46–54 select no more than two using supplied authority and capacity. 54–60 confirm experiment record and four-week review.

Experiment template: hypothesis; specific process change; scope; confirmed owner; start/end; observable evidence; risks; stop/review trigger. Candidate experiment, not pre-approved: require content approval-status check at the end of week 1 and escalate pages lacking an approver. Evidence needed: whether this would have exposed the 11 late pages earlier.

효과가 있는 이유

1
Evidence-status separation prevents confident causal stories from replacing what the project actually recorded.
2
Bounded experiments convert learning into testable change without overloading the team.

결과 확인

Are observations separated from interpretations and causal hypotheses?
Does the agenda avoid individual performance judgment and motive inference?
Are experiments limited, owned only when confirmed, and reviewable?

안심하고 사용하세요

자주 묻는 질문

이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변

What should I prepare before using “Create a project retrospective meeting agenda”?

For “Create a project retrospective meeting agenda,” prepare Project baseline and outcomes, Participants and context, and Retrospective scope. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Create a project retrospective meeting agenda” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A psychologically safer retrospective agenda with evidence prompts and bounded experiments—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Create a project retrospective meeting agenda”?

No model run is recorded for “Create a project retrospective meeting agenda” as of 2026-08-29. Treat it as a model-portable template rather than a compatibility claim. Run the worked example first, keep every constraint visible, and compare the output with the result checks before using it on real material.

더 많은 탐색 방법