How do I pitch and back up the concept of pointing to my team?

Question

I am a scrum master with a small team of developers. We have had a difficult year but this year we are trying to get back into doing things correctly. Part of this includes getting back into pointing properly, but I am receiving a lot of push back. The developers do not like the idea of pointing, and they think it is a waste of time, especially since we are developing tools for internal clients only. My manager is pressuring us to point, however.

My only argument is that by pointing we can quantify to senior management and other stakeholders how much we have accomplished.

How else I can back up the concept of pointing?

Answer 1

That's one side of the coin. It may resound more with your team members to phrase the argument as,

"If you, team, do not [story]-point, you cannot quantify to management how much work you can deliver. Management loves this because they want you to deliver an infinite amount of work in an iteration. Management will give you more work than you can do and expect you to do it if you don't story-point. They will blame you, the team, at the iteration end for not delivering because you didn't set their expectation of what was reasonable using story-point estimates and velocity. Help me by story-pointing work, so that as a team we can say "no" to our managers when expectations are unreasonable."

You could also point out some other benefits of story pointing exercises: -Understanding which items should be started sooner rather than later in the iteration -Using story points as a discussion vehicle to clarify requirements/scope -Using story points to say "no" to an epic in disguise

Answer 2

If your goal is really to provide people external to the team with a good idea of your productivity, I'd argue story points aren't the technique you're looking for.

That's not to say you shouldn't be estimating work but bear in mind that story points are really a measure for the team not externals. As WBW says in their answer, they can be used to identify stories that are too big for an iteration and to drive conversation between team members over complexity. Velocity (average points per iteration) is a great way to measure how consistent the team is and to guide how much work to commit to for a sprint.

The problem with points (or velocity) for reporting outside the team is that they estimate the complexity/effort of a story not the value that the story delivered. There is nothing to say an 8 point story is going to deliver any more value to the end user than a 1 point story, just that it is simpler to do.

For external communication, focus on the value the customer/stakeholder/user is getting. Ideally, you should have sufficient tracking in place to measure the positive effects of delivering your product.

For example, if you are adding features to a tool your contact centre staff use for logging calls, your key measures might be things like time to log a call, speed to retrieve an account, average caller wait time.

Showing how the software you're delivering has a positive impact on actual business measures tells people a lot more about how your team is doing than story points.

Answer 3

TL;DR

None of the parties involved appear to understand the purpose of story points. Your management probably wants to use them as a performance metric or forecasting tool, and your development team is likely resisting a prescriptive process with the likelihood of having points converted to units of time anyway.

Unless your organization fully buys into the value proposition of both estimates (as opposed to fixed targets) and estimating by size (instead of duration), there is little value in using story points at all. Story points have utility, but only when used properly and for their intended purpose.

Don't Report Story Points Completed; Report Value Delivered!

My only argument is that by pointing we can quantify to senior management and other stakeholders how much we have accomplished.

Story points are estimates of complexity, not measures of performance. Likewise, velocity is an estimate of team capacity over time, and has no relationship to the value delivered. Misusing either of these metrics for reporting rather than estimation almost always ends in tears.

If you want to report value, you need to find a better reporting metric. In general, the Product Owner is the person best-placed to determine a given feature's value to the business or its customers. Alternatively, if your Product Owner has used a system like relative weighting to prioritize the Product Backlog, you might consider using either the value or value-minus-cost from the exercise for your reporting needs.

Reasons to Use Story Points

Entire books have been written on this subject. It's worth noting that most agile frameworks don't require estimates in story points; you are certainly free to estimate in ideal hours, dollars allocated, or any other metric that works for your team.

The main reason agile practitioners choose story points over other metrics is that they don't directly measure time. Consider the following:

A key tenet of agile estimating and planning is that we estimate size but derive duration.

— Cohn, Mike (2007-10-03). Agile Estimating and Planning (Kindle Locations 1288-1289). Pearson Education. Kindle Edition.

If you accept this axiom, then measuring in story points would allow you to quickly estimate the relative size of a story. Derivation of time is then usually done at the release planning level (measured in iterations), rather than within iterations where capacity planning is more important.

You can read the extant literature to determine for yourself whether the converse (e.g. attempting to derive iterative capacity or release schedules from per-feature time estimates) is possible, practical, or reliable. Perhaps more importantly, you will have to form your own opinion about whether it is faster or slower to estimate in units of time, and what the trade-offs in overhead vs. accuracy really are.

The prevailing wisdom is that story points takes less time to estimate, and that they lead to more reliable estimates within an iterative framework. The effectiveness of your implementation may vary.