We know that StoryPoints are "a relative measure of size that can be applied to Stories and Epics." Beyond this simple statement there is not much about StoryPoints that we can all agree on - teams and organizations are free to estimate and use StoryPoints as they see fit. Well, I want to use them to aid in Project (not Sprint) Management, and in this talk I present a way to define StoryPoints for this purpose. Come and hear words like "Ideal Effort", "Intrinsic Difficulty", "Function Points", and "Earned Value", and how StoryPoints become the basic currency for Release budgeting and metrics.


Many Scrum/XP Teams are using StoryPoints to size their Stories, and they are using StoryPoints to be a relative measure of “actual effort”. This is a horrible mistake if you also want to use the StoryPoints to help manage a Project, and has led to many issues, including:

  • The “my StoryPoint is not your StoryPoint” mantra that many people have, which just gives up on the notion of normalizing StoryPoints across Teams; and
  • The “we need to resize our Stories constantly” issue, which leads to consternation on the part of Project Managers.

One of the biggest issues, called the “grandmother of all issues” by Ken Schwaber, is that the creation of technical debt will gobble up our projects. By using StoryPoints as a surrogate for actual effort, I see many projects resize things constantly in order to account for the additional effort needed to produce the same Scope. This confusion of Size and Effort is a serious killer of projects.

The Project Management discipline has struggled with the differences between Size (used to manage Scope) and Effort (used to manage Cost) for decades, resulting in discussions about Earned Value, Function Points, and so on. This is a difficult problem. In my opinion, Scrum (with its incremental development) actually makes it easier to solve this problem.

This is what the talk is about.


Outline/Structure of the Talk

There are a few basic principles and concepts that are covered in this talk:

  • That StoryPoints are (for Functional Stories) a Relative measure of Ideal Effort, where Ideal Effort is the amount of effort something would take if there were *no* impediments, where impediments include things like Team Ability, Technical Debt, Organizational Noise, and SME Availability (which I refer to as Environmental Variables).
  • StoryPoints can be estimated by using “natural measures”, which are elements we can count (or estimate), are found either in the problem domain or the logical design, and we believe are correlated with Ideal Effort. For example, for websites, a natural measure might be “widgets on a page”.
  • That there is a Standard “natural measure” that is useful in many domains, the COSMIC Function Point, which counts data movements in and out of the System.
  • That COSMIC Function Points, therefore, are *also* a relative measure of Ideal Effort (for Functional Stories), so I can (and will) define a (functional) Story Point as a work unit that represents the production of a Function Point. Note: a work unit is something that consumes effort and produces value while it is being done - a standard PM concept.I introduce the concept of a “natural measue”, which is something we can count (or estimate) that is inherent in either the problem or logical solution to the problem. I then include a brief description of COSMIC Function Points, which count data movements into and out of the System Under Consideration, and are one such “natural measure” of Size. In what follows, I assume that this is the measure we are using…
  • I present an Estimation Game script that shows how StoryPoints can be estimated for *all* stories, and that the resulting StoryPoints are work units that represent the amount of work it takes to build one Function Point - this normalizes the StoryPoint, as Function Points don't move (data either moves or it doesn't)
  • I describe why this is a good way to define StoryPoints

o   This definition makes it so that trends in Velocity represent systemic changes in the Environmental Variables, which helps quantify their affects

o   That StoryPoints defined like this are appropriate for use in Earned Value metrics, whereas those defined as representing Actual Effort are not

o   that tying StoryPoints to Function Points "normalizes" the StoryPoints so that they can be compared and combined across Teams.

  • I describe Using StoryPoints as currency in a Project

o   Budgeting StoryPoints for Epics in order to consume them as the internal Stories are extracted and developed

o   that there are standard methods for estimating these StoryPoint budgets for functional Epics

  • I describe the issue of managing Technical Debt

o   since Technical Debt is an intrinsic part of the code, working with it is a drag on Velocity

o   if Technical Debt needs to be removed, StoryPoints should be spent, since this provides value

  • Finally, I show how these StoryPoint estimates (budgets) are an intrinsic part of a Release Plan

o   Release Plan is basically "we'll develop Use Case 1, Use Case 2, using HH hours, costing $DD dollars, in YY sprints", along with a Series of Planning Assumptions, which are independent and can be monitored separately by the PM

-   The Use Cases consist of NN Function Points

-   This will take MM StoryPoints to Develop

-   Each storyPoint will take HH hours on average

-   Each Hour will cost $DD dollars on average.

  • With this info, the PM now has things to monitor and work with in order to balance cost, scope, and schedule

This is an advanced talk, so I plan to deliver the material in approximately the order given above, with frequent opportunities for the participants to ask questions and get clarification

Learning Outcome

I am hoping that the Attendees will understand that importance of StoryPoints for Project/Release Management. Furthermore, I hope that they will understand the difference between Size and Effort, and that each can be estimated.

This course is for those intending to use Scrum for software Projects. The attendees will leave with:

  • An understanding that StoryPoints are not a trivial matter.
  • An understanding of what StoryPoints need to look like to make them useful for Project Management

Target Audience

ScrumMasters, Product Owners, Project Managers, Program Managers

schedule Submitted 5 years ago