The secrets behind story points and agile estimation


Dan Radigan Dan Radigan

Estimation is hard. For software developers, it's among the most difficult–if not the most difficult–aspects of the job. It must take into account a slew of factors that help product owners make decisions that affect the entire team–and the business. With all that at stake, it's no wonder everyone from developers to upper management is prone to getting their undies in a bunch about it. But that's a mistake. Agile estimation is just that: an estimate. Not a blood-oath. 

There's no requirement to work weekends in order to compensate for under-estimating a piece of work. That said, let's look at some ways to make agile estimates as accurate as possible.  


In agile development, the product owner is tasked with prioritizing the backlog–the ordered list of work that contains short descriptions of all desired features and fixes for a product. Product owners capture requirements from the business, but they don’t always understand the details of implementation. So good estimation can give the product owner new insight into the level of effort for each work item, which then feeds back into their assessment of each item's relative priority.

When the engineering team begins its estimation process, questions usually arise about requirements and user stories. And that's good: those questions help the entire team understand the work more fully. For product owners specifically, breaking down work items into granular pieces and estimates via story points helps them prioritize all (and potentially hidden!) areas of work. And once they have estimates from the dev team, it's not uncommon for a product owner to reorder items on the backlog. 


Involving everyone (developers, designers, testers, deployers... everyone) on the team is key. Each team member brings a different perspective on the product and the work required to deliver a user story. For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.

Likewise, design changes require not only the design team's input, but that of development and QA as well. Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don't feel included, and compromises the quality of the software.


ストーリーポイント VS 時間

従来のソフトウェアチームは、日数、週数、月数という時間数で見積もりを提供します。しかし、多くのアジャイルチームはストーリーポイントへ移行しています。ストーリーポイントは、 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 のように、フィボナッチ数列に似た形式で作業の相対的労力を評価します。直感的にわかるものではないように聞こえるかもしれませんが、この抽象化は、作業の難しさを中心にしてチームに厳しい決断を下すよう促すので、実際に役立ちます。以下に、ストリーポイントを使用する理由をいくつか示します。

  • 日付は、日常で必然的に生じるプロジェクト関連外作業を考慮に入れていません。このような作業には、E メール、ミーティング、面接などがあり、チームメンバーが関わっている場合があります。
  • 日付で見積もると日付に執着してしまいます。相対的見積もりは、この執着を取り除きます。
  • 各チームは作業を微妙に異なった規模で見積もります。つまり、速度 (ポイントで測定される) が必然的に異なってきます。このため、速度を武器として使用して策を弄することは不可能になります。
  • Once you agree on the relative effort of each story point value, you can assign points quickly without much debate. 
  • Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time. 

Story points and planning poker

ストーリーポイントから開始するチームは、プランニングポーカーという方法を使用します。Atlassian では、プランニングポーカーは全社的によく行われています。チームはバックログから項目を取り上げて少しの間話し合い、各メンバーは心の中で見積もりを立てます。次に、メンバーは一斉に数字が書かれたカードを上げて、各自の見積もりを示します。全員が一致していれば申し分ありません。一致しない場合、しばらくの間 (といっても、長すぎてはいけません。数分です)、様々な見積もりの根拠について話し合います。ただし、見積もりはハイレベルのアクティビティであることを忘れないでください。チームが枝葉末節にとらわれすぎていたら、深呼吸をして、概要レベルの議論に戻します。

Ready to give it a try? 


個々のタスクは、作業が 16 時間を超えないようにしてください。(ストーリーポイントを使用している場合、たとえば、上限を 20 ポイントとします。) これより規模が大きいと、高い信頼度で個々の作業項目を見積もることが非常に困難になるだけです。その信頼性がバックログの最優先項目では特に重要です。チームの 16 時間 (または 20 ポイント) の閾値を超える見積もりがある場合、それをさらに細分化して見積もりをやり直す必要があることを示しています。



Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools (like Jira Software) track story points, which makes reflecting on and re-calibrating estimates a lot easier. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.

Like everything else in agile, estimation is a practice. You'll get better and better with time.