How to Size Stories and Account for Impediments
There is no accepted definition of what a StoryPoint represents, other than that it is a unitless, relative measure of size to be used for both Stories and Epics. I want to give definitions I consider useful, and that’s what I’ll be doing here. First I will deal with Acceptance-Based Stories – those Stories that are defined by Doneness Criteria – rather than a Time-Box:
StoryPoints(Story), for an Acceptance-Based Story, is a relative measure of Ideal Effort, which is the effort it would take to develop the Story (meet both the Acceptance and Doneness Criteria) if everything were as it should be.
What does ‘as it should be’ mean? Good question. Here is what I mean:
- Your Team has the people it needs, and they are all top-notch; the Team has the domain knowledge, the skills, and the development environment it needs to do its job – there are no impediments due to a lack of Team Ability.
- Your Code is Clean, protected by both Unit and Functional Tests, and the Technical Documentation is both minimal and sufficient – there is no Technical Debt.
- The Organization provides a safe, learning environment; Team Members are allowed to focus on their Team’s work and are not sidetracked by excessive meetings and other distractions – there is no Organizational Noise.
- There are Subject Matter Experts available who have the knowledge or expertise you need, when you need it – there are no impediments based on SME Availability.
In other words, when estimating Acceptance-Based Stories we need to ignore Impediments caused by Environmental Variables (Organizational Noise, Team Ability, Technical Debt, SME Availability, and others specific to your environment); we ignore the portion of the effort that is based on the Team and the Organization and focus only on the Story’s Intrinsic Difficulty.
On the other hand, ‘as it should be’ doesn’t mean you can expect magic or miracles: the laws of physics have not been repealed; you haven’t suddenly been gifted with transporter technology; Superman, the Hulk, and Einstein aren’t suddenly going to show up as Team Members; and so on. It’s ‘as it should be’, not ‘as it might be if only ABC and XYZ were true’ where ABC and XYZ are fanciful, non-realistically-attainable, things.
I hope you understand what I’m getting at here…
This definition is a natural extension of XP’s Ideal Time, which is the “amount of time it would take to develop the Story if there were no distractions or disasters.” I like this definition, and I am merely extending it to be a relative (not absolute) estimate, to explicitly exclude consideration of any and all Impediments, and to make sure we’re not expecting miracles…
This definition is a complicated expression of a simple idea; that all StoryPoints should take about the same amount of relative effort if everything were the way it should be. A two point Story should take about half the effort of a four point Story, all small Stories should take about the same amount of effort, and so on. However, because of impediments, some StoryPoints are harder than others; some two-point Stories may take more effort than some eight-point Stories – those darned Environmental Variables often get in the way.
This notion – that Stories with the same StoryPoints value should take the same amount of effort – leads to a discussion of Time-Boxed Stories. It will be short and sweet…
We use Time-Boxes for ill-defined Stories – those Stories with ‘mushy’ or non-existent Acceptance Criteria. Examples of such Stories include ‘Refactor Module ABC,’ ‘Analyze Use Case XYZ’ and ‘Make page 123 faster.’ Generally, Stories like these need to be time-boxed, or there’s no guarantee they’ll ever get finished. These Stories can be time-boxed in Days or Hours, but I recommend that they be time-boxed with StoryPoints, like ‘Do 1 SP’s worth of Analysis of Use Case XYZ,’ as this allows the Team to self-organize and self-manage while doing the Story. It is the Team’s job to figure out exactly how much Actual Effort to spend, based on their experience about how much Ideal Effort a StoryPoint should take. I find that the ‘StoryPoint Time-Box’ concept allows the Team to do what it feels necessary to provide the demonstrable value the Story represents, without going overboard, and while spending the right amount of effort.
Sizing stories and accounting for impediments is discussed in greater detail in chapter 3.7 of Exploring Scrum, which you can purchase on Amazon.