Peteon Rails

Scrum Masters embarking on a project or converting a team from conventional development to Scrum often run into one big roadblock: convincing the stakeholders to use Agile Estimation techniques. One of the most important and success-inducing things you can do when estimating an Agile project is to abandon the “hour” as the unit of estimation in favor of “story points”.

The idea is, instead of using “hours” to estimate how long a story will take to complete, you instead have the team use an arbitrary figure called a “story point”. So, a new input field on a web page might be “1 point”. A new login screen is probably “3 points”. And adding a new payment gateway may be “8 points”.

Each iteration will then have a point value assigned to it. For example, Iteration 6 may be “23 points”. When your team completes all of the functionality, the team’s velocity is “23 story points per iteration”. Savvy Scrum Masters will calculate Velocity as the moving average of the last 4 iterations.

Why bother ditching the “hour”? Here’s why:

1. It eliminates preconceived notions about how much code can be written in a day.
2. It eliminates the “Day” as an important unit of measure.
3. It forces you to forecast completion of your project based on evidence. If you estimate in hours, you’re already forecasting. If you estimate in points, you’re simply measuring complexity in relative terms and relying on past performance to predict future results. In software, that’s a good thing.
4. It helps to gel the team. If Joe can do a feature in 8 hours, and Eric can do that same feature in 12 hours, there’s going to be a disagreement on how much to estimate. Instead, shouldn’t Joe and Eric agree that “Two new fields on the screen is twice as big as one new field on the screen?” Over time, the difference in coding productivity between your team members will be abstracted away by the estimation technique, which allows each team member to play to their own strengths without being measures in widgets-per-hour.
5. It ends up being more accurate after 2 or 3 iterations.
6. It avoids the mythical man month problem. By insisting that you forecast based on evidence, a manager cannot offer to double the team size and cut the deadline in half.

There are lots more benefits. There are books full of the benefits. Read them.

In convincing stakeholders to allow the engineering team to use Story Points, I have run into several objections. Here they are, along with the answers that I use.

Objection: But if your numbers don’t map to hours, how do I know how long something will take?

Answer: You use Velocity, as calculated by the evidence of progress your team produces, and map target dates based on what actually happened instead of a gut feeling.

Objection: But then how do you know how much more you can get done by adding more resources to the project?

Answer: Again, you use the evidence. Adding a new team member doesn’t immediately produce a faster tempo on a project. There is no way to know how a new team member will contribute to a self-organizing team until you see them perform. As that team member ramps up, the team will eventually start producing more story points per iteration. You will only take on work in a sprint that you historically could complete, and as you start completing all of the committed work faster, your velocity increases. The team is continually winning instead of lagging. If you instead use “hours” to estimate, you’d be tempted to just add “40 hours” to the velocity. That’s a guess, and it’ll be wrong every time.

Objection: But then how do I calculate what a project costs me?

Answer: If you have all of the members of a Scrum team properly allocated, and you have an accurate forecast of the completion date, then you can easily calculate the project labor cost using very simple math. If you use hours instead, you use the same simple math, it’ll just be inaccurate.

Objection: But then how do I know how much overtime to ask the developers to work in order to meet my deadlines?

Answer: Forcing overtime to meet deadlines is a Scrum Smell. It means you are planning poorly, sticking to unreasonable deadlines, sacrificing quality, or the team is failing because of some organizational, process, or performance issue. That said, it is sometimes necessary to work overtime. Rather than tell everyone they need to work 10 extra hours this week to make the deliverable, it’s actually BETTER to say to your team: “We have 10 more story points to complete in 2 days, and we’re only burning 3 points per day.” If the Scrum Master is good, the team will know what to do. And they’ll do it as a team.

Good luck! Let me know how it goes.