MSF Agile: Risk vs Story Points?

Question

I'm working through the creation of an initial set of user stories for a new project, and I'm using MSF Agile for the first time. I've got about 100 user stories, and I've assigned them all to areas and iterations, but the next step for me is assigning all of their Risk, Story Points, and Stack Rank values. However, I find that I'm assigning nearly mirror opposite values for risk and story points, i.e. all me 1-High risk stories are 3 story points, and all my 3-Low risk stories are 1 story points.

The MSDN documentation defines these fields as such:

"Story Points: A subjective unit of measure that captures the size of a user story. If you assign more points to a user story, you indicate that more work is required to implement it."

"Risk: A subjective rating of the relative uncertainty around the successful completion of the user story. You can specify the following values: 1 - High, 2 - Medium, 3 - Low"

I find that these go hand in hard for pretty much every situation I've come across. In your experience, what are some examples of high risk stories worth only few story points, or low risk stories worth many points?

I need help in reasoning about these differently. How should I be thinking about these?

Answer 1

It shouldn't be that way at all.

It's possible to implement a large piece of story with no risk at all. The risk doesn't mean it will take a long time, instead it's the chance it would take WAY longer than you think.

An example of story 3 risk 1 might be a set of GUIs that must be meticulously positioned and each validated by the customer. You know it will take a long time, but you don't expect more than one or two iterations per screen.

Example of story 1 risk 3 might be interfacing to a web servers that you THINK you know the API for. Probably trivial, potentially annoying (What if there is some nasty cookie you have to emulate or something--Just making this up, not personally a web dev).

Story 1 risk 3s are going to be more rare because you should probably examine them more deeply and bring down the risk a little, but in some cases by the time you've done that you might as well have implemented it...