Close

フィーチャーキックオフミーティング


Before you dive into development, gather your team for a feature kick-off meeting. What's on the agenda? Walkthroughs, feedback, and alternative ways to solve the problem.

このプレイの目的

新しいフィーチャーの価値に対する自信を育み、丸投げするのではなく協力して仕様に磨きをかけます。

If you're struggling with shared understanding, value and metrics, or proof of concept on your Health Monitor, running this play might help.

Copy link to heading Copied! 詳細を見る
なぜこれが必要なのか

This is the one – the feature your customer research tells you will differentiate your product and delight your customers. You totally should've shipped this last release, so let's get cracking on it.

Whoa! Hold your horses, cowpoke. Your team have no context. You've probably made assumptions in defining the problem this feature solves. There's no agreement on how to measure the feature's success. And let's face it: in all the excitement, it's possible some design or technical challenges were overlooked.

Time to rustle up your team and step through the details before filling your backlog with user stories. Else, you'll start development with more questions than clarity.

誰に参加してもらうべきか

このためにチーム全員を集めましょう。

ユーザーのチーム
スタッフ

6 ~ 9 人

時計
所要時間

60 分

難易度: 低
難易度

プレイの実施

Make sure your new feature is more than just a concept before holding a kick-off meeting. But don't wait until the design is fully baked, either.

準備物

ホワイトボード

マーカーまたはペン

付箋紙

ゴム製のニワトリのおもちゃ

準備

コンセプトを構築する

Before the kick-off meeting, the product owner or designer should build out a low-fidelity user journey map and have a rough idea of what to use for success measures. Share these with the team before the session so they can come prepared.

Schedule your feature kick-off meeting in a space with big walls or whiteboards. Arrive a few minutes early, and use that space to put up the user journey you've mapped out.

ステップ 1

フィーチャーの概要 (10 分)

Welcome everyone to the kick-off meeting and start by providing an overview of the feature and the context around it. Describe the problem or opportunity it'll address, and how that ties in with broader goals or initiatives. Introduce your target user persona and the value this feature will provide them, citing research or supporting background information. Then lay out your thoughts on measuring success.

Remember: the idea is to do "just enough" spec'ing and scoping before the feature kick-off. There are supposed to be holes and gaps at this stage – the purpose of this meeting is to bring the team together to start filling them.

不適切なパターン

共有が遅すぎる: 仕様が「決定」だと見なされると、チームからのフィードバックを基に方向転換する機会を失う可能性があります。

ステップ 2

フィードバックを受ける (10 分)

Before jumping into the user journey, pause for feedback from the team. If you're met with silence and shakes of the head, use some of these questions to help get your team talking:

  • このフィーチャーで提供しようとしているものについて、私たちは共通の理解をしているでしょうか?
  • このフィーチャーに対し、あなたは何を望みますか?
  • このフィーチャーに対し、どのような不安がありますか?
ヒント
ヒント

ターゲットカスタマーのペルソナの観点からフィーチャーを導入し、実現します。

ステップ 3

ユーザージャーニーのウォークスルー (15 分)

Remember that user journey you developed before the kick-off meeting? Walk through it from start to finish. Call out how the user will discover the feature, how they'll interact with it, and how they'll leave it. As you walk through, talk about how the feature will address the problem space, reduce customer friction, or otherwise add value.

Instead of pausing for feedback during the walk-through, ask everyone to jot their thoughts down on sticky notes. This prevents any single team member from inadvertently hijacking the walk-through and leading you down a rabbit hole.

ステップ 4

批評と代替ソリューション (20 分)

Go back to the start of the user journey map. For each stage, have everyone post their sticky notes and discuss the team's feedback. (It's fine for people to jot down new questions or concerns on stickies, too.)

Forget about what each team member's usual role is. This is a time for everyone to imagine ways the feature might fail (security vulnerabilities? usability flaws? technical constraints? etc.) and suggest ways to avoid them.

すべての質問と懸念を、プロダクトオーナーの回答や決断と一緒に文書に記録します。

ステップ 5

まとめ (5 分)

現在のチームの取り組みを明確に理解するには、他にどのような情報が必要ですか? それはなぜですか?

Assign any unanswered questions about the feature to a team member, with a due date for coming back with the answer. Typically, answering them involves additional user research, fleshing out edge cases that surfaced during the meeting, or thinking though pieces of the technical design.

ヒント
ヒント

チームのプロジェクトの標準的な進め方にフィーチャーキックオフミーティングを加えましょう。チームのバックログが増える前にフィードバックループが定期的に回ってきます。

成果の確認

チームで一通りのヘルス モニター セッションやチェックポイントを実施して、改善しているかどうかを確認してみましょう。

その他のパターン

地理的な境界を越えたチーム

このプレイは、複数の場所に分散するチーム向けにカスタマイズすることができます。早めに Confluence ページ上でコンセプトを共有し、VC が備わっている部屋を予約します。

フォローアップ

キックオフミーティング後にチームメンバーが新しい質問を思い付いた場合、その質問と予想される回答を仕様に追加します。

その質問を適切なチームメンバーに割り当てます。提案された回答が気に入った場合、割り当てられたメンバーは単にその回答に同意するだけでもかまいません。

プレイブックがもっと必要ですか?

下のボックスにメールアドレスを入力すると新しいヘルスモニターやプレイが追加された時に通知が送られます。

Thanks! Now get back to work.

フィードバックがありますか?

アトラシアンコミュニティサイトで質問やコメントをしてください。