• /
  • 로그인
  • 무료 계정

Planning poker and points budgets

Planning poker is a consensus-based estimating and planning technique. To start a planning poker session, the story reporter or liaison presents a story to the team. Then, the team all votes (at the same time, to prevent groupthink) on how difficult they think the story is.

Most agile teams that estimate with planning poker use cards that follow a Fibonacci sequence. We've found over the years that those large jumps weren't very helpful to us in estimating, and that we estimated better with smaller numbers. So we use fairly small, granular numbers that roughly break down to 1 point ≈ 1 day.

Note that even though each of the possible scores have approximate time values associated with them, we vote in points, not time. Scoring with points prevents getting into weedsy debates about exactly how long something will take, and instead focuses us on the requirements and difficulty of the story.

Poker card definitions

These how we define our poker cards:

Card

Value

¼

An hour or two. Anything smaller than this isn't worth bringing into a sprint or even ticketing—just do it right now.

½

About half of an "ideal" day. We define an "ideal" day as one without meetings or interruptions. Using "ideal" days makes it easier to estimate a story without litigating the details of how we spend our time.

1

About one "ideal" day. This is one of our most common story sizes.

About one and a half "ideal" days. This is our other most common story size.

2

About two "ideal" days.

3

About three "ideal" days. We jump from 2 straight to 3 to avoid unrealistic granularity in our estimates.

5

About a week of work.

7

About a full sprint (two weeks) of work. We very rarely use this card—a ticket that takes a full sprint on its own is almost always too large and should be chunked into smaller, incremental tickets.

Break!

"I need a break." When someone plays a break card, we finish estimating the current story then immediately take a five minute break.

Defer

No strong opinion. Don't play this card on the first round of poker! Seeing wildly different estimates is a sign we don't have a shared understanding of the work. Playing an early Defer card can mask that uncertainty.

How we calculate the points budget

In order to ensure we're not filling up our sprint with more "ideal days" of time than we realistically have available, we calculate the points budget based on the actual output of the team. Over time, we've found writers average 0.6 (technically, 0.57) points per day.

This value is totally unique to each team! A high number doesn't indicate a more productive team, and a low number isn't a problem. Story points are only meaningful within a team.

If you're starting a new team or new process, you'll need to zero in on the ideal number of points per writer. An easy way to figure out the right budget is to have the team vote in retro on whether to increase, decrease, or keep the same budget next sprint. You'll overshoot or undershoot a few times, but after a couple sprints you'll get a good sense of what constistutes a sustainable pace.

Once you know your baseline, calculating the budget is straightforward:

  1. Take the number of writers, and multiply by the number of days in the sprint.
    • To make the math easy, let's say 5 writers and a 10 business day (2 calendar week) sprint. Or, 50 person-days total.
  2. Subtract out time off days, plus 1 day for each day of hero duty.
    • Let's say we have 1 writer on vacation in Maui, and 1 day of hero time per day. 50 person days, minus 10 days of vacation and 10 days of hero time, gives us 30 person-days.
  3. Multiply the number of days times the average velocity per writer, per day.
    • Our average velocity is 0.6 points/writer/day. 30 person days multiplied by 0.6 would give us an 18 point budget for the sprint.

Because we work in two squads, we calculate a separate points budget for each squad ahead of sprint planning.

← Meetings and ceremonies

We welcome thoughts or questions on our handbook! The easiest way to get in touch is to file a GitHub issue.

문제 신고
Copyright © 2022 New Relic Inc.