Scrum is a leading framework for agile development methods. However, even the best scrum teams can get bogged down in time. The main reason is usually poor time management, which is where agile methods and the scrum framework are meant to save time.
This is a problem that can be experienced by everyone from the project management novice to the most seasoned Scrum Master.
Fortunately, the signs can be spotted early on. The problems start when timeboxes (a method of time management with clear goals) are no longer respected. It is customary to have timeboxes around sprint planning meetings, but this is not just a formality. In the literal sense, Scrum would not work without a defined timeframe. But what to do if you can’t get everything done within the pre-determined timebox? It’s difficult, isn’t it? This is why not everyone understands the Scrum framework properly.
So in this article, we’ll show you how to make the most of your sprint planning time.
When to do Sprint Planning
First, a quick review of Scrum basics: The Scrum framework breaks down a project into small sections called sprints, which usually last between 1 and 4 weeks, with a meeting at the start of each sprint to discuss the plan for the future.
During Sprint Planning, the project team reviews the work recorded in the Product Backlog to determine which items on the list will be tackled in the next Sprint, and at the completion of every Sprint, the project team holds a retrospective meeting to discuss what went well and what needs improvement.
Then the next Sprint starts with another Sprint Planning session. The whole Scrum Team should take part in Sprint Planning together with the Scrum Master and the Product Owner. Also, if possible, Sprint Planning should be done early in the week so that you have four consecutive days of productivity.
For now, remember that Sprint Planning begins with each Sprint.
What’s in a sprint plan?
The sprint planning session defines the sprint content based on what the scrum team can accomplish, and it also helps align the whole team by sharing the sprint planning goals.
Typically, the Product Owner announces the Sprint Goal at the beginning of the Sprint Planning meeting. The Product Owner is responsible for making sure that all the work the team is working on adds value to the product, and they determine the goals that need to be met to achieve that.
For example, if your project is building a SaaS web app, the product owner might set a goal of “launch a user dashboard by the end of the sprint” and use that goal to demonstrate the value of the app to stakeholders. The team uses the sprint goal as a guideline to decide which items from the product backlog to tackle during the sprint.
The Product Backlog collects all the Development Team’s goals for the entire project. However, it is impossible to tackle all the Product Backlog items in one Sprint. The golden rule is to set goals for each Sprint and prioritize these items.
Sprint planning is centered around negotiation:
the Product Owner first shares the terms and the Scrum Team
responds by offering what they can do.
This process continues until both parties are happy (or at least as long as they can). The sprint structure ensures that the product owner has enough new features to prove value, and the project team can focus on building a quality app by breaking down the work into smaller chunks.
The sprint planning template from monday.com is a great example of how information can be organized visually.
As the sprint planning discussion progresses, the scrum team lead and product owner move items around on the dashboard to reflect collective decisions on the board.
As a Product Owner, I would like to have the User Dashboard ready by the end of the Sprint, but in reality it will take more than two weeks to create and configure the dashboard, so I will create a framework for the dashboard with no content in case the Product Owner needs to show progress to stakeholders or shareholders.
It’s a fine balance to keep a project moving, but with a few tips you can create a sprint planning session that works for everyone.
Tips for successful sprint planning
The monday.com team has learned about sprint planning through hard work and many failures. In this section, we will share some of the best practices for sprint planning we have learned from our past experiences.
We’ll also explain how to use monday.com Work OS, so read on.
1. Clean up your backlog
One of the best ways to make your sprint planning meeting more efficient is to have a second separate meeting beforehand. While having multiple meetings might seem unagile to some, it makes a lot of sense.
First, the entire scrum team does not need to attend. A pre-meeting can be a small gathering of only the project manager (or scrum master) and the product owner. By having a forum for discussion in advance, you can anticipate the risk that the sprint plan will not go as planned if something unexpected happens.
For example, during Sprint Planning, several members of the project team are discussing a story in the backlog – they might disagree about what that story means, or they might have completely misread where that story fits in the overall Sprint.
In such a case, the sprint planning session will definitely go over its timebox.
To avoid this downward spiral, many agile project teams employ a technique called backlog grooming, backlog refinement, or story time.
Private backlog grooming sessions are where team leads can reorganize the backlog to reflect the latest strategic priorities and also add clarifying context to fuzzy stories.
場合によっては、バックロググルーミングセッションにチームを招待することもできます。この場合、各ストーリーをスプリント計画に組み込む前に、セッション内でそのストーリーについて質問する機会が与えられます。しかし、チームの生産的な時間をあまり浪費したくないという場合は別の方法もあります。それが、monday.com の機能バックログテンプレートです。
小規模なバックロググルーミングセッション中に、チームリーダーとプロダクトオーナーはテンプレートを更新することができます。チームのメンバーは誰でもログインして、すぐに加えられた変更を確認することができます。
こうすることで、スプリント計画の現状をすばやく視覚的にテンプレートに落とし込み、全員で同じ認識を共有することができます。プロジェクトマネージャーの方は、チームからの質問に対してオープンに対応するようにしましょう。
2. レトロスペクティブ会議を個別に設定する
また会議？と思った方もご安心ください。重要なのは会議の数ではなく、非効率な会議を減らしていくことです。
通常の会議はもちろん、スタンドアップ、1対1など、あらゆる種類の会議を厳密に管理し、最大限の効果が得られるタイミングで行うことが重要です。
そのため、スプリント計画会議とレトロスペクティブ会議の時間は必ず分けて設定します。
プロジェクトマネージャー的な思考では、同時に行うことで時間を節約できると考えがちです。1つのスプリントが終わり、別のスプリントが始まるタイミングで、できるだけ両スプリントの間に無駄な時間をあけたくないと考える人もいるでしょう。しかし、このアプローチには2つの問題点が潜んでいます。
まず、2種類の異なる会議を同時に行うとそもそもの長さが2倍になり、重要な計画作業が始まる時に注意力を欠いてしまう危険性があります。それに、スプリント間のブレイクはまったく無駄ではありません。レトロスペクティブ会議と計画の間の時間は、実際にはさまざまな情報を処理するためのとても重要なタイミングなのですから。
この期間中、チームメンバーは自分自身で前のスプリントから得たことを振り返り、それらの教訓に基づいて行動する方法を試すことができます。
レトロスペクティブ会議では、monday.com のスプリント・レトロスペクティブ会議テンプレートを使用してチーム全員の考えを整理しましょう。
2つの会議を同じ日に行う場合は、少なくともランチタイムを挟むことをおすすめします。さらにおすすめなのは、金曜日の午後にレトロスペクティブ会議でスプリントの週を締めくくり、月曜日の午前に計画セッションを設けて、新しい週とスプリントをフレッシュにスタートすることです。
最後のスプリントから得た教訓をテンプレートにしっかりと反映させたら、チームメンバーもすぐに進め方を体得してくれることでしょう。
3. バックログのアイテムごとに値を割り当てる
プロダクトオーナーがスプリント目標を設定したら、チームでその目標をどれだけ実現できるかを決めていきます。
ここでは、このフェーズで知っておくべき用語をいくつかご紹介します。
ベロシティはスプリント計画の基本単位で、チームが平均スプリント中にどれだけのことを達成できるかを測定します。チーム全員が自分のベロシティを把握しておく必要があります。
ストーリーポイントは、スプリント計画をゲーム化するためによく用いられます。タスクまたはストーリーのポイント値は、完了するまでにどれだけの作業が必要かを示す相対的な尺度です。
ストーリーポイント（SP）はタスクにかかる時間を具体的に見積もるのが難しい場合でも、作業量を比較するために役立ちます。
スクラムポーカー、またプランニングポーカーは、ストーリーポイントを割り当てるために使用されるプロセスです。プレイの手順は次の通りです。
- 各チームメンバーに、片面に1〜10の番号が印刷されたカードを渡します。
- スプリント目標の一部であると判断したすべてのバックログアイテムを取り、一度に1つずつ発表します。
- 各アイテム用に、チームメンバー全員がストーリーポイントの見積もりを記載した裏向きのカードを置きます。
- チームリーダーがカードをシャッフルして裏返します。すべての見積もりが比較的近い場合（たとえば、すべて3、4、5）、数値を平均して最終見積もりを出します。
- 見積もりが離れている場合（たとえば、同じタスクに2と9）、外れ値の数値を記載した全員がその数値を主張します。そして順番に、自分の付けた数値の理由について議論します。
- 合意するまでステップ3〜5を繰り返します。
- 現在のスプリント目標に適合するすべてのバックログタスクを完了するまで、次のアイテムに進みます。
スクラムポーカーは、全員の意見を聞きながら合意に達するための便利な手法です。上記の解説が現段階では複雑すぎると感じる場合は、monday.com のスクラム計画テンプレートをぜひご活用ください。
プランニングポーカーなど、ストーリーポイントを割り当てるゲーム用にカスタマイズすることもできます。
すべてのタスクにストーリーポイントを割り当てたら、スプリントの最終スコープが見えてきます。その後は、チームにタスクを割り当てて開始するだけです。
4. 一定期間のデータを収集する
スプリントはそれ自体が独立したものではありません。各スプリントは、前のスプリントのイテレーションです。スプリントごとに、チームのベロシティについてより正確な情報が得られます。
過去のベロシティを理解すればするほど、より正確に将来を予測することができます。たとえば、monday.com の R&D チームでは、1ストーリーポイントが1人の開発者のおよそ1日の作業時間に相当するというアプローチを採用しています。10日間のスプリントには、各開発者に9ストーリーポイントの作業を割り当て、バグや予期しない遅延に対処するために1日の空き時間を設けています。
このような情報を保管しておきたい場合は、デイリータスクマネージャーのテンプレートが役立ちます。
チームメンバーが毎日の終わりにこのボードを定期的に更新することで、全員のベロシティに関する大規模なデータがすぐにボードで確認できるようになります。
スプリント計画後のステップ
スプリント計画会議の後は、チームが下したすべての決定をきちんと記録しておきましょう。スプリントのスコープ、全員の個別タスク、バックログへのすべての変更、その他発生したものがあれば必ず更新してください。
It may seem like a lot of work (and it is), but team leaders can spend the whole day summarizing their post-session work. But if you’re familiar with monday.com, you don’t have to worry. monday.com Work OS helps you organize your data with advanced workflow automation. And because it’s built by experienced project managers, it’s designed to help you use your project time efficiently.
What if all story point estimates were automatically updated in a high-level project roadmap, or all tasks assigned to team members were automatically entered into a daily task tracker?
In Work OS, linked templates update each other so that all records of project progress are always up to date.
Conclusion
So, the most important key to effective sprint planning is to plan in advance and then plan for the meeting. Second, make sure your plan focuses on the actual team members, not on the perfect scrum structure.
Collecting enough data to understand how your team is doing will help you confidently plan your sprints moving forward, and a positive feedback loop will give you more confidence in your next development.
Check out our monday.com templates today and start building the tools that will help your team achieve their goals.
今すぐ使ってみる