LinearでAtomic Scrumを行うための準備

タスク実行記録チャートのイメージ

目的

上述したように、スクラムは「チーム」で実践することを意図したフレームワークだ。 そのため、本記事の読者の中には「一人」と「スクラム」という対照的なワードに対して矛盾を覚える方もいるかもしれない。 実際に一人スクラムの効果について懐疑的だという意見も見かける。

しかしスクラムの本質は「経験主義」と「リーン思考」だ。 何をどのように進めたら良いのかを経験から学び（経験主義）、ムダを省いて本質的な問題と向き合う（リーン思考）ことで、チームマスタリーを得た状態を目指す。 経験から学ばずに思い込みによって間違った方向に進み続けてしまうことや、ゴールの達成には役立たない些末な問題に囚われてしまうことは、個人であっても陥りがちな問題だ。 経験主義とリーン思考を身につけるためのトレーニングとしてスクラムを捉え直すと、スクラムチームを構成するメンバーが一人であったとしてもそのエッセンスは有益ではないかと考えている。

プロダクトバックログ

プロダクトバックログは、プロダクトの将来の状態を表すプロダクトゴールと、具体的な改善内容を表すプロダクトバックログアイテムのリストで構成される。 ここで「プロダクト」という言葉を使っているが、自分の場合は具体的なものに限らず、価値を実現した状態全般を「プロダクト」と定義している。 一人スクラムの場合のステークホルダーは主に自分や家族、友人などになり、例えば「フランス料理のフルコースを作れるようになる」というプロダクトゴールに「簡単なオードブルを作る」というプロダクトバックログアイテムが紐づく形になる。

プロダクトバックログアイテムの管理には Jira を利用している。 Jira には見積もりの割り当てや集計などの機能があるので、他のタスク管理ツールよりも一人スクラムを実践しやすいと考えている。 ただツールは本質ではないので、一人スクラムを継続するのに苦にならなければどんなツールを使っても良いと思う。

スプリントゴールを立てる

スクラムではスプリントと呼ばれるタイムボックス内で作業を進める。 自分の場合はタイムボックスを1週間に設定しており、月曜にスプリントを開始し、日曜にスプリントを閉じている。

月曜の朝はスプリントプランニングを行う。 そのスプリントの価値をスプリントゴールとして表現し、その達成に必要なアイテムをプロダクトバックログから選択し、実行可能な計画を立てる。 スプリントゴールがないと、日々の忙しさや娯楽の誘惑などに負けてスプリントを放棄してしまう可能性が高いので、面倒であっても設定したほうが良い。

バーンダウンチャート

• Scope
  • 全てのタスク？
• Started
  • スプリント内のタスク？
• Completed
  • スプリント内の完了タスク？

バーンダウンチャートの見方がいつまでたってもわからん

Github連携

まず開発に入る時はブランチを切ると思いますが、Linearでは以下のようにコピーした名前でブランチを切ります。
ブランチをRemoteにPUSHしたあと、PRを作成すると自動的にそのブランチ名と同じタスクと連携して、タスクをIn Reviewに移動してくれます。
ブランチ名をつけるのに迷わなくて済むし、PRとタスクが紐づいているおかげでそれぞれから確認することが簡単です。

Slack連携、純粋な実行ログBotとして垂れ流しといてもよいかも？

目的に向かってスプリントしない。代わりにサイクルという概念を使い、チームの健全なモーメントを維持する。
用語を作り出さない。プロジェクトはプロジェクト。

結果として、スクラムの用語との対応付けが必要になってしまっている？

ロードマップからプロジェクトをつくり、プロジェクトから目標日とサイクルを計画する
バックログをすべてとっておく必要はない
個々の issue を可能な限り小さくスコープする
(後述するが、Linear では user story を書かない)
Changelog を書く

小さくスコープする→タスクが散らばってみえそう

ロードマップを時間、ゴール、テーマに基づいてマイルストーンに分割する。それぞれ成功の意味が違う。

ここはスクラムのスプリントゴールとは考えが少し違いそう

価値のあるプロジェクトに取り組む。どうしてもやらなければならないプロジェクトはロードマップに組み込んで作業の種類と強度を均す。細々とした issue は1つのプロジェクト（「バグウィーク」など）に束ねて楽しくやる。

細々としたissueはメインissueとして起票しない→よいね

インパクトのある（顧客体験を向上する）基幹的プロジェクトを優先する。プロジェクトリードをローテする。ロードマップを10個の中途半端なプロジェクトで終えるより3つの重要なプロジェクトを出荷するほうがいい。
ロードマップは不可能になることなしに価値あるものであるべき。常に見積もりよりも多く時間がかかるものだし、ロードマップのプロジェクトは少なすぎるよりちょっと多いほうが出荷のモチベーションになるしモーメントを上げられる。

それはそう

Linear 自身は四半期のはじめにロードマップを2週間くらいかけて作る。プロジェクト単位のリリース日は決めないが、外部調整が必要なローンチやスコープの限定のために期日が必要なこともある。

「２週間くらいかけて作る」
具体的にどんな計画になっているのか？

新機能をイネイブラー、またはブロッカーの除去と解釈する
今やるべきか、後でもいいのかを考慮する

用語がよくわからん・・・

何かをやることを考えたり議論したりする代わりに、やるかやらないかを決めてその日のうちに着手する

着手ベースだ

何をすべきかわからない数週間もあるが、直感を信じて何かをし、フィードバックを得る。素早く動いて学習するようオペレーションを設計しておけば意思決定を修正できる。
スタートアップは進捗しすぎたり意思決定を1回間違って死ぬことはまずないが、ゆっくりすぎたり諦めたりすると死ぬ。

その通りだと思う。ここまでシンプルに表現しているのはあまり聞かない気もするが

Linear ではユーザーストーリーを書かない。代わりにタスクを簡潔にわかりやすく説明する issue を書く。Issue はタスクを伝えるために書く、十分なコンテキストと共に。
ユーザーストーリーはカーゴカルトになっている。回り道であり、タスクを曖昧にする。書くにも読むにも時間がかかる。エンジニアを、プロダクト全体のUXを考える代わりに要件をコーディングする機械的な役割に矮小化してしまう。プロダクトレベルの話をタスクレベルに持ち込むのでスコープが切りづらく複雑になる。普段の会話と馴染まない。
わかりやすく簡潔にシンプルな issue を書いてタスクを説明する。UX をタスクレベルではなくプロダクトレベルで議論する。ユーザーストーリーを作る時間で、代わりにユーザーと話し機能を検討する。

具体的にどう違う？

具体的なタスクや issue を説明する。タスクは成果物を伴う。タスクでないものはイシューで記述するのではなく、プロジェクトのアイデアや大きな機能のアイデアである可能性があるのでもっと具体化する必要がある。例外はあり、たとえば機能に取り組む前に設計や技術を検討するときにイシューを作り、あとで分割したり成果物を作ったりできる。

大事そうな概念

直接的で短いイシュータイトルを付ける。リストやボード上で目にするものなのでスキャンしやすいタイトルにする。説明はオプショナル。ユーザーフィードバックは要約するより引用、リンクしたほうがよい。
チーム全員が自分でよくわかっているイシューを書く。タスクを完了に移したり要件リストにチェックを入れるために作るのではなく、プロダクトやプロジェクトの成果物にフォーカスできる。

同意！

チーム全体でプロダクトレベルで顧客体験を議論し、プロジェクトを具体化してロードマップを作成してから仕事をプロジェクトチーム単位に委任する。これによってみながニーズ、制約、要件を深く理解するので、タスクレベルで UX を明らかにしなくて済む。

「言わなくてもわかるようにする」というニュアンス？

作っているものを見せる。危険に思えるがむしろ競合がスピードに怯むかもしれない。

いいね

そのために Changelog を書くとよい。ユーザー数が少ないときに changelog を書くのは馬鹿げていると思うかもしれないが、毎週何が起きたのかを思い出せて、継続的に出荷するやる気が湧く。ユーザーにとってもプロダクトがよくなっているとわかるし、投資家にとっても進捗が見える。スピードが足りないと感じたときに、これまで達成したことを見返すこともできる。

大事だなぁ

Linear は現時点ではスタートアップや小規模の企業を主要なターゲットとしているので、その哲学にエンタープライズなビジネスが主な対象である昔からのアジャイルとの違いがあるのは自然だろう。Linear の考え方が適用できるのは、社内の安定した仕組みを自動化するために決められた予算と納期で堅実に作る開発ではなく、顧客へ価値を届けることとそのための繰り返される学習に重きが置かれる開発である。（これはわかりやすさのための対比であって、実際の開発はスペクトルのどこかに位置する。）

2年経って改めて見ると、ユーザーストーリーのくだり以外は素直なカンバンだなという気がします（当時の自分はカンバンを一般的なビューの1種としか思っていなかった）。原文を読み返してみると至って健全なアジャイル指南だなあ…あとデザインスプリントのフレーバーがたまに感じられる。
スコープを交渉する必要のない代わりに継続的適応的に実験、学習しなければいけないプロジェクトやプロダクトではスクラムを採用する必要性は確かに薄く、その場合むしろ1つ1つのチケットのリードタイム、すなわちバックログに載ってから完了されるまでの時間の最適化に焦点を当てれば十分でしょうし、プロセスも比較的軽いと思います。
とはいえ運用してみた経験としてはスクラムで Linear が使えないわけでは全然ないです。歩み寄ってくれています。

「スクラムをする」ことが目的ではないことを認識しておく。

プロダクトバックログ

スクラムガイドとは順番が前後しますが、実際にプロジェクトを開始するときはまず最初にプロダクトゴールを決めると思いますので、「プロダクトバックログ」を先に説明します。

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。
スクラムガイド p12 「プロダクトバックログ」

「プロダクトの改善に必要なもの」は"improve"を直訳してしまっているので 「プロダクトを完成に近づけるのに必要なもの」 と読み替えてください。
その「必要なもの」一つ一つがプロダクトバックログアイテム（PBI）ですね。

マイルストーンには名前と期間を設定し、詳細テキストには、
このプロダクトバックログ一覧がすべて完了した時点でユーザーが得られる価値
この期間ではやらないこと
などをMarkdown形式で書きます。これがプロダクトゴールになります。

マイルストーン

• プロダクトゴール（最終成果物）
• マイルストーン（途中の成果物）
• スプリントゴール（スプリント毎の成果物）
  のように、1～2ヶ月程度ごとにマイルストーンを挟む3階層にするのが良いと思います。

人類の精神は10カ月先とかの目標に全力で集中できるようになっていない

プロダクトバックログアイテム

なお、ここでBacklogの課題のテンプレートを設定しておくと便利です。筆者は「PBI」種別のテンプレートにユーザーストーリーを表す「____が____できる」というタイトルを設定しています。
各PBIの見積もり（後述）を記入し、ドラッグ＆ドロップで取り組む順番に並べ替えたらプロダクトバックログのできあがりです。

→Linearでいうと、Scopeなのかな、Projectのタスクなのかな？

理想的にはPBIをユーザーストーリーマッピングで言う「ストーリー」の一部にしたいところですが、筆者は各PBIが1スプリント以内に終わることをより重要視しています。そのため、たとえば
ユーザーがログインすると空の画面が表示される
ユーザーがフォームに入力して送信ボタンをクリックできる（送信はしない）
のように、あえて未完成の状態をUI上で確認できるところで区切る場合もあります。

!PBIが1スプリント以内で終わると、ベロシティが計測でき、Backlog Sprinterの統計画面に表示されます。

見積もり

こちらのKosuke Aokiさんの記事がわかりやすかったのでリンクします。

筆者は以下の感じで雑に見積もっています。
確実に簡単でぱっと数時間で終わる＝1
1日くらい＝2
数日くらい＝3、5
ちょっと大変そう＝8
めっちゃ大変＝13＝基本使わない。分割するべき

ずっと先まで正確に見積もる必要は全くありません。Scrumは経験主義です。「最初から完璧な計画」とかいう不可能なものは求めません。最初は雑だった計画が走りながらチームの経験と計測データによってこまめに更新されて正確で信頼できる計画になっていくことを目指しましょう。
また、スプリントを重ねるうちにチームの熟練度や理解度が上がり、2,3,5あたりの感覚が大きく外れなくなっていきます。

スプリントの価値

PBIの粒度をユーザーストーリー（ユーザーにとっての価値）としていれば、完了したPBI＝ユーザーから見た進捗＝そのスプリントの価値となります。

どのように成し遂げるか

子課題はできるだけ細かく分けて、1日でいくつか終わるくらいの大きさにするのがお勧めです。
例えば「開発」に未知の技術の「調査」が必要な場合、時間が読みにくい「調査」だけの課題を作り、「開発」の課題と分けます。
後述のデイリースクラムで、「昨日はこれとこれとこの課題が完了です」とテンポよく完了に放り込んでいくと気分がいいです。気分がいいと集中できてスピードが上がります。
この子課題が、スクラムガイドに記述されているスプリントバックログアイテムにあたります。

スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。
スクラムガイド p12 「スプリントバックログ」

リファインメント

まわりのPBIと子課題を見比べながら、前に見積もったポイントが妥当かどうかみんなで考えます。
「うーん、これ8よりは大きいなあ。その上は13？…いやしかし…10くらいを選ばせて欲しいなあ」となったら大きすぎるので分割のサインです。
PBIを分割したら子課題をドラッグ＆ドロップで新しいPBIに移します。

ベロシティとバーンダウン

この画面で、プロジェクトの進み具合を確認できます。ベロシティは実線の3週移動平均だけ見て、点線の週次データは気にしないで大丈夫です。
PBIのベロシティが落ちてきている場合、様々な原因が考えられます。
PBIの分割がうまくできてない
難しい箇所にどうしても時間がかかっている
モチベーションが維持できていない
集中しづらい外部要因がある
チームで話し合って原因を突き止め、解消しましょう。

ベロシティは「高値安定」が理想です。ずっと同じ程度のベロシティが維持できているチームは、次のスプリントも計画どおりにいく可能性が高いからです。

リファインメントはスプリント中のいつやってもいいそうです。
開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は⼀⽇を通じて頻繁に話し合う。
スクラムガイド p10 「デイリースクラム」

スプリントレビュー

スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。
スクラムガイド p10 「スプリントレビュー」

CI/CDがきちんと機能していれば、スプリントレビューのために特別にアプリケーションをデプロイする必要はありません。今動いているアプリケーションをみんなで確認して、次のスプリントおよびプロジェクトの残りについて話しましょう。

Issue

Githubのイシューと同じ意味合い
Issue作成はcがショートカットキーに割り当てられている

Workflow

• Issueのステータスを遷移してワークフローを管理する
  • Kanban式のワークフロー
    • Kanbanって結局何なんじゃ？
• ブランチを発行すると、Issueのステータスは自動的にActiveになる
  • プルリクの下書き、発行、レビュー、マージに沿って変わる

Cycle automations move issues to and from the backlog and you can set issues to close and archive on their own so lists stay relevant.

• to and from ?

Cycle automationsは、バックログへの移動やバックログからの移動を行う機能であり、問題を自動的に閉じたりアーカイブしたりする設定が可能です。
これにより、リストが常に関連性を保つことができます。
具体的には、Linearのようなツールでは、サイクルの完了時に未完了のタスクを自動的に次のサイクルに移動させたり、一定期間経過した後に閉じたタスクを自動的にアーカイブする機能が提供されています。
このような自動化により、チームは手動でバックログを管理する手間を省き、効率的に作業を進めることができます。

Special Statuses

• Backlog is a status category in Linear. Each team has its own backlog and teams can add additional backlog statuses to group issues down further.
• Triage is an optional status in Linear that makes it possible to review issues before accepting them and moving them to your team's backlog or cycles.

• バックログ：ステータスの一つ
  • ワークフロー＝ステータスの変動ということ
• バックログはLinearにおけるステータスカテゴリです。各チームには独自のバックログがあり、チームはさらに問題をグループ化するために追加のバックログステータスを追加することができます。
• トリアージはLinearにおけるオプションのステータスであり、問題を受け入れる前にレビューし、チームのバックログやサイクルに移動することを可能にします。

Project View

Initiative

イニシアチブはプロジェクトを整理し、会社が目指す目標とその進捗状況を示します。各イニシアチブには、手動でキュレーションされたプロジェクトリストが含まれており、ワークスペースレベルの単一のイニシアチブビューに表示されます。これにより、複数のプロジェクトと長期にわたるタイムラインにわたる高レベルの計画が可能になります。

Linearの一般的な利用方法では、ツール自体に「スクラムマスター」という明確な役割が強制されるわけではなく、その責任はプロダクトマネージャーやエンジニアリングリーダーなどに分散されることが多いとされています 。しかし、スクラムではスクラムマスターにファシリテーション、障害物除去、コーチングといった特定の責任が定義されています。Linearを用いてスクラムを実践する場合、チームはこれらのスクラムマスターの責任を誰がどのように果たすのかを意識的に決定し、ツール設定とは別にプロセスとして定義する必要があります。これは、Linearがスクラムの「仕組み」をサポートする一方で、役割遂行といった「人的要素」についてはチームによる積極的な管理が求められることを意味します。

Cycles の設定はチーム設定から行い、期間（例：1～2週間、2週間が一般的 ）、開始曜日、クールダウン期間（必要に応じて）、予測期間などを構成します 。

Cycles の主な利点として、未完了のIssueが次のCycleへ自動的に持ち越される点が挙げられます 。これは非常に便利で、スプリント終了時の手作業によるクリーンアップ作業を大幅に削減します。また、ベロシティの追跡機能も重要で、Cycleの進捗グラフにはエフォート、スコープ、完了率が表示され、チームのベロシティを視覚化するのに役立ちます 。

Linearの思想には「スプリントではなく、勢いを生み出す」という考え方があり、Cycleは必ずしもリリースと厳密に結びついているわけではないと示唆されています 。ユーザーはスクラム実践のためにCycleをスプリントにマッピングしますが、このニュアンスを理解することで、継続的なフローを目指すLinearの設計意図を汲み取ることができます。実際のスクラム運用では、多くの場合、Cycleの完了を実証可能なインクリメントの提示と連携させることになるでしょう。

LinearのCycle設計、特に未完了Issueの自動ロールオーバーや「勢い」を重視する思想は、スクラムの伝統的な解釈で時折見られるスプリント持ち越しに対する硬直的な捉え方よりも、適応的で心理的安全性の高いアプローチを促します。未完了Issueのロールオーバーがシームレスに行われ、チームの勢いを維持することに焦点が置かれるため 、スプリント毎に100%の完了を目指すプレッシャーが軽減され、持続可能なペースと継続的な価値提供にチームがより集中できるようになります。この微妙な違いが、チームの士気や長期的な生産性に好影響を与える可能性があります

Projects: エピックと長期ビジョンの管理

Linearの Projects 機能は、「明確な成果物または計画された完了日を持つ、フィーチャーまたは大規模な作業単位」を管理するために設計されています 。これらはIssueをグループ化し、複数のチームにまたがることができます。スクラムにおいては、Linearの Projects はエピックの管理に最適です。

エピック管理のための Projects の利用方法としては、まず各エピックに対して新しい Project を作成します 。その際、プロジェクトリーダー（エピックオーナーやPOに相当）を割り当て、ターゲット期日（長期的なエピックの場合は大まかなものでも可）を設定します。そして、その Project （エピック）をより小さな Issues （ユーザーストーリーやタスク）に分割し、プロジェクトの概要ページや進捗グラフを通じて進捗を追跡します 。

さらに長期的な計画のためには Initiatives 機能（旧称Roadmaps）が役立ちます 。Initiatives は複数の Projects をグループ化し、戦略的な製品努力を調整し、高レベルのタイムラインを提供します 。これにより、日々の作業（Cycle内のIssue）をより大きな目標（Projects/エピック）や戦略的方向性（Initiatives）に結びつけることが可能になります。Linearの思想としても、日々の作業を大きな目標に結びつけることの重要性が強調されています 。

LinearにおけるIssue、Cycles、Projects、Initiativesという構造は、日々の開発作業と戦略的なビジネス目標を連携させるための明確な階層を自然に提供します。これは多くのスクラム実装において課題となる点です。スクラムではプロダクトゴールが存在し、スプリントはその達成に貢献するスプリントゴールを目指します。エピック（LinearのProjects）は、このプロダクトゴールを分解したものです。Linearの機能セットは、このトレーサビリティを容易に実現し、スプリント（Cycle）で行われる全てのタスクが、より大きな戦略目標に明確に紐づいていることを保証します。これにより、焦点が定まり、価値提供の透明性が向上します。他のツールやセットアップでは、このようなマッピングが手作業になることも少なくありません。

• バックログアイテムはTriageに積んで、優先順位付けをする
• スプリントバックログ：Cycleと紐づくIssue
• インクリメント:Cycleで完了したIssue
• スプリントプランニング：バックログからIssueを選び、Cycleに追加する
• スプリントゴール：Cycleで達成すべき具体的な目標、またはProject概要、マイルストーン
• エピック：Project

Linearの Issues: 単なるタスクを超えて

LinearはIssueテンプレートをサポートしており （はNotionテンプレートに言及しつつLinearにも存在することを示唆）、バグ報告、機能仕様書、QAリクエストといった反復的なタスクに対してテンプレートを使用することで一貫性を確保できます 。テンプレートのフィールド例としては、ステータス、優先度、担当者、ラベル、サブIssue、依存関係、期日、見積もりポイントなどが考えられます 。

Linearはタスクレベルでの「ユーザーストーリー」を軽視する一方で、スクラムにおけるユーザー中心の精神は、Linearが提唱するように Project （エピック）や機能仕様の段階で徹底的なユーザー体験の議論を確保することで維持できます 。スクラムはユーザーニーズの理解を重視し、それはしばしばユーザーストーリーを通じて表現されます。Linearの考え方では、個々の Issue から詳細なユーザー中心の議論の場を Project の概要や機能仕様書に移すことで、この両立を図ります。Issue は、そのより豊かなプロダクトレベルの理解から派生した、明確で実行可能なタスクとなります。これにより、チームはLinearの効率的なIssue追跡を活用しつつ、作業の背後にある「なぜ」を十分に理解することができます。

プロダクトバックログ の習得

Linearのバックログビューは、まだアクティブなサイクルに計画されていない将来の作業を管理し、優先順位付けするのに役立ちます。新しいIssueはここで直接作成できます 。

Triage は、新しいIssueのためのLinearの受信箱として機能します 。開発者は Triage から迅速にアイテムを処理し、割り当て、ラベル付けし、移動させることができます 。これはバックログ管理の重要な部分です。

優先順位付けのテクニックとしては、Linearがサポートする優先度ラベル（緊急、高、中、低）の利用 、バックログビューでのアイテムの並べ替えが挙げられます。Linearは「管理可能なバックログ」を奨励しており、すべてを無期限に保持するのではなく、重要なアイテムは自然と再浮上するという考え方です 。

Linearの機能（Triage、優先度ラベル、シンプルなバックログビュー）と、その思想（管理可能なバックログ）は、受動的で際限なく増え続けるリストではなく、より動的で積極的にキュレーションされるバックログ運用を促します。新しいアイテムが積極的に処理され（Triage）、優先順位が付けられ、古くなったり関連性が薄れたりしたアイテムは暗黙的または明示的に整理される（再浮上しないことによって）というワークフローが示唆されます 。これは、バックログがしばしば情報の「ゴミ捨て場」と化してしまう一部のスクラムチームの状況とは対照的です。Linearは、チームを継続的なリファインメントと集中へと導き、これはスクラムにとってより健全な状態と言えるでしょう。

Labels: 組織化と可視性の強化

Labels は、Project や Cycle との関連付けを必要とせずにIssueを整理するために使用されます 。ラベルはワークスペースレベル（全チーム共通、例：「Bug」）またはチームレベルで作成できます 。Label groups は1段階のネストを可能にし（例：Type/Bug）、Issue整理の選択肢を増やします 。

プロダクトバックログリファインメントは、プロダクトオーナーと開発者が協力してプロダクトバックログアイテム（PBI）に詳細、見積もり、順序を追加する継続的な活動です 。これは正式なスクラムイベントではなく、継続的なプロセスです。

Linearをリファインメントで活用する方法としては、Backlog ビューで Issue をレビューし 、Issue の説明に詳細を追加し、大きな Issue をより小さなものに分割します（必要であればサブIssueも活用 ）。見積もりを追加し（LinearはTシャツサイズまたはポイントをサポート ）、バックログ内の Issue の順序を変更するか、優先度フィールド/ラベルを更新することで再優先順位付けを行います。依存関係について議論し、Linearの Blocker 機能 を使ってそれらをマークします。

Linearの「ユーザーストーリーではなくIssue」という考え方 に従い、リファインメントでは、厳密なユーザーストーリー形式に固執するのではなく、タスクが明確で具体的、かつ十分に理解されていることを保証することに焦点を当てます。「なぜ」という部分は Project （エピック）レベルで議論されます。

Linearが「明確でシンプルなIssue」を重視していること を考慮すると、Linearにおけるプロダクトバックログリファインメントは、各 Issue が真に実行可能であり、その成果が明確に定義されていることを保証することに重点を置くべきであり、単にフィールドを埋めるだけでは不十分です。これは、バックログのDEEP基準における「Ready（準備完了）」の状態と一致します。「準備完了」のPBIは、明確で、テスト可能で、スプリント内で完了できるほど小さいものです。Linearの思想 は、「明確に定義された成果物を持つタスクを記述する」Issueを推進します。したがって、Linearを使用したリファインメントセッションは、ユーザーストーリーのテンプレートに準拠することよりも、「このIssueは曖昧ではないか？この特定のタスクにとって『完了』が何を意味するのか、全員が理解しているか？十分に小さいか？そうでなければ、どうすればより明確で小さなIssueに分割できるか？」といった厳密な問いかけに焦点を当てるべきです。この実践的な焦点により、PBIは真に Cycle の準備が整った状態になります。

https://linear.app/docs/initiative-and-project-updates

Healthってなんだろうって思ったけど
そのProjectがどれくらい更新されているものなのかを示す指標かな