Points, Hours, Capacity

Question

Let's say we work in two week sprints.

The team has 6 developers.

8 hours per day, 10 days, multiplied by 6 would equal total 480 hours.

Multiply that by .7 to get at an ideal developer day and you get 336 hours.

Take into consideration any PTO or meeting times and you reduce it further.

Let's say for simplicity's sake I arrive at 330 hours for the sprint.

Let's also say that those hours are divided evenly at 55 hours per developer.

Where is the correlation between planning the sprint, assigning points, and filling each developer's 55 hour capacity, since points don't correlate to time necessarily?

If there is a different way of doing it (I did all hours in the past), please point me in that direction.

Answer 1

EDIT:

First off, you have a bigger problem.

The team that I've taken over doesn't currently do retrospectives or sprint reviews sadly.

You may have tagged the Question as scrum, but you're not doing Scrum. Before you try to fix any of the numerous issues that pop up as you try to implement your Scrumbut, you need to first try Scrum by-the-book. If you don't have experience with the baseline, then you won't be able to know how best to adapt Scrum for your organization. https://ronjeffries.com/xprog/articles/jatbaseball/

---

Why are you asking? For estimation, for reporting to management, or for planning?

For estimating? Ignore time entirely. Developers estimate in points, not time.

For planning? Look at past velocities and average them. If, over the past 5 (2-week) Sprints, you completed 84 Story Points, then the Team's velocity is 84 points over 10 weeks, or 8.4 points per week, or 1.2 points per day. Do not try to plan for individuals. That's an anti-pattern. Plan for the Team. Likewise, you should be able to ignore time-off and the like; the averages will smooth that over.

For reporting? Do it in whatever format management expects. If points, give the points. If time, get the points, convert to time using the ratio determined above, then give the time.

---

EDIT2:

if I ask for the team's availability during the sprint, and John indicates that he has PTO Thursday and Friday at the end of the sprint, and I know he is going to be out for a total of 16 hours. How does this information impact the total capacity if not calculating based on hours, and velocity has not been established?

There are three approaches I'd suggest suggesting to your Team and see which they prefer, or if they have a better idea.

A) Since planning is a fuzzy discipline in the first place, just ask the Team to take it into account when determining how many story points to take into the Sprint

B) Calculate how many man-hours are missing and multiply the rest by your historical velocity to determine how many story points to accept. If you have a Team of 3 and 1 person is missing 2 out of 5 days, then you're overall missing 2 out of 15, so multiply your velocity by 13/15.

C) Just don't worry about it. Overall your velocity will take PTO into account if you don't worry about it and average over enough data.

Answer 2

Points

Story points are a way of measuring effort using relative sizing. They are deliberately not time based for several reasons including:

• People are naturally better at relative estimating than they are at absolute estimating
• Time-based estimates have an influence on the way people do the work (e.g. "The estimate was 2 hours, but I have taken 3 hours already so I should rush to finish")
• Time-based estimates have a tendency to become deadlines

Capacity

It is useful for a team to know their capacity so they can plan how much work to bring into their next sprint.

There are lots of different approaches to calculating capacity, but using historical data is often an effective approach. Hence a lot of teams use a rolling average of the story points they completed in previous sprints as a measure of their capacity.

Hours

Hours are useful in some circumstances, such as:

• If your organisation bills based on individuals' hours
• If you have team made up of specialists and you want to know if any one individual is over/under loaded
• Some teams like to limit the maximum duration of tasks (e.g. "We like to avoid tasks that take more than a day to complete")

It is not unusual for a Scrum team to combine using both story points and hours. They use the story points to calculate their capacity and estimate hours for individual sub-tasks of the stories. This can give the benefits of both approaches. The downside is that estimating becomes a significant overhead cost.

Answer 3

Based on my understanding from various scrum trainings and chasing the agile dragon for a few years, here's my take.

Hours should not be mapped to points. That seemed really antithetical to me early on, but I've embraced it. More importantly managers need to make sure that people work the right amount of hours per day, some employees you might need to be more aware of than others. I've found that teams in general are pretty good about this because in that collaborative environment it becomes evident pretty fast if people aren't pulling their weight.

We've switched to story points and the first few iterations were spent figuring that out for each team, but now each team has a pretty good idea of what its point capacity and velocity is. So while it definitely freaked out my waterfall brain early on, I now have:

• Employees working the right amount of hours, on average. Handled by team dynamics and the occasional discussion with (typically) more junior developers. Sometimes it's talking a developer down from working too much.

• Teams that can estimate their iteration capacity pretty well.

A reality is that even if you estimate hours, you'll probably be wrong. So it doesn't really do much anyway and is an un-solveable rubix cube.

Answer 4

In Scrum the most important reason to estimate is so the team can decide what fits into a Sprint. It's upto the team to use their time most effectively during the sprint. If the team has spare bandwidth at the end of the sprint they can always pick up something extra from the backlog.

Don't fall into the trap of equating points with hours or days. Leave it as a relative measure and then track the actual velocity over time. In practice people do the same with hours and days estimates as your 0.7 figure suggests. Estimates in hours and days are arguably not really that at all - they are often just relative numbers. Stating the estimates as points rather than hours makes that relative reality clear to everyone.

Answer 5

The key point with iteration planning in XP, and perhaps sprint planning in Scrum as well, is to work towards getting good estimates of what you can get done. We do this by measuring velocity, i.e. how much actual work the team gets done per iteration.

To measure "work that got done," we need some units for it. You can use hours, but this can get confusing for two reasons:

1. Developers don't spend every hour of every day doing nothing but development: within the project there's also planning, research, training, experimentation with new tools, and the like; beyond this there's also the usual administrivia that the company requires of employees that does not directly contribute to the development process.
2. The estimates and velocity you produce are interelated: if your team is in a steady state you can double all your estimates and immediately double your velocity. This is clearly meaningless, but again, people get confused by the idea that you can suddenly switch from doing 300 to 600 "hours" a week (especially if your team is actually in the office for substantially less than 600 person-hours) and everything is still just fine.

This is why I suggest using points instead of hours; it helps make clear that you're measuring arbitrary amounts of "work" here, and the hours or weeks taken are what comes out of comparing your estimate for what particular group of stories you'd complete in an iteration with what actually got completed.

For assigning points, I usually suggest that everybody start by assigning stories one, two or three points. (Anything bigger should be considered for breaking down into multiple stories.) For the first iteration I don't even make an estimate; we just ask the customer to rank stories in the order we'd like them done, have everybody pick one on which to start working, and see where we are at the end of the iteration. That gives us an estimate for the next iteration, but generally not a reliable one; I find it usually takes 4-8 iterations before things settle down. During this time the team will tweak how they assign points (estimates for the same story may be changing iteration to iteration), and this is likely to change how much work people feel a point is. That's fine; as I mentioned above both point "sizes" and velocity can change and the other will adjust appropriately.

You can't use any of this to determine "developer capacity" or try to see what developers are "not doing enough work"; if you do that you introduce an incentive to game the system by individually doing "more points," which directly works against the ability of the system to produce accurate estimates. Further, developer capacity in the abstract varies depending on what they're working on; a database expert may be slower at doing front-end work and vice versa, but that's expected and fine, and certainly not a reason to weaken your team overall by too much specialization or, worse yet, siloing.

As you look at your system over time, it's critically important to keep in mind the primary goal of your planning: good estimates. For anything that you're considering changing, or that's just arising as time goes on, ask whether it's going to hurt the estimation process, particularly by generating incentives to inflate "amount of work that was or will be done." Those need to be nipped in the bud or you end up back in the world of project managers living in an alternate reality defined by their spreadsheets and distant from the actual state of the code.

Answer 6

I always thought of "points" as ... well ... "specific thumb-tacks on the project planning board." They're things that you've got to hit – not a way of estimating how long it might take to hit them.

If you have just inherited a team that is, shall we say, "not enthused," then the first thing that I would probably do is to take a very, very close look at what their previous sprints consisted of, including the list of goals that they said they were going to hit. "Did they hit them?" And ... well ... "was their list of milestones actually any good?"

To borrow from politics discussions, there's definitely such a thing as "SINO = Scrum In Name Only.™" Is "thorough and relevant pre-analysis" actually being done? Are they really advancing the project? Or, are they merely going through the motions?