Are story points hot or overrated? Weeks, days, and hours seem more intuitive for humans. Story points, however, extend the familiar time component with complexity and risks, for greater accuracy of estimations. They also add another “safety feature” – average velocity per sprint, that allows for very realistic planning.
Portfolio management software, such as BigPicture, supports both story points and the traditional units of time – hours, days, and weeks, as well as person-days and person-hours1.
Should users convert story points to days and vice versa? What are the pros and cons of story points? Which industries and teams might consider estimating tasks in story points?
What are story points?
Story points address the everlasting problem of underestimation in project management. Have you ever planned to fence your family home from sunrise to sunset only to discover you needed two weeks for that? You were not aware of the complexity (fence has a gate, tension mechanism, and reinforced corner poles) and risks (underground rocks along the survey line).
The same is true for nearly any project.
Here are some facts about story points:
- Story points are “a measure of complexity” (time + difficulty + risks) used by some agile teams instead of time and money units.
- Story points are units of relative value used to compare and prioritize work chunks.
- Thanks to story points, “easier” tasks (with fewer story points), and those bearing more customer value, go up in the backlog and make it to the market quicker.
- Unlike meters, or hours, there is no world standard, or universal value, of a story point. Story points are a “currency” of the team; they reflect the current level of experience of the members. Like a currency, story points might change their “value” over time (“inflation” or “deflation”).
- When a team increases its velocity, it means the team is able to burn more story points during a sprint (a good thing).
- 1 story point of team A ≠ 1 story point of team B.
- In real life, the software industry makes use of story points most. Graphic design, UX, and marketing teams in many other industries follow suit
- Story points work better with teams than with individuals. Teamwork is a prerequisite for story points.
Story points in 4 simple steps
Here is a simple story points workflow, fully supported by our BigPicture:
- When a new project begins, the team takes a task they had completed in a past project (ideally several times), neither too complex, nor trivial, and that becomes the model task – worth one story point.
- The ‘to do’ tasks from the current project get estimated (collectively, by all team members) based on how complex the tasks are relative to the model task. Bibliography tends to recommend using Fibonacci numbers (1, 2, 3, 5, 8, 13, 21), but that is not a must. You can try plain integers, too.
Optional: consider double estimates – both in story points and time units – if your management board or clients demand dates, impose deadlines, or when you use portfolios on top of projects.
- Once the agile project has commenced, the product owner periodically prioritizes tasks in the backlog. The less complex the task (fewer story points) and the more business value it carries, the sooner it should make it to the market.
- After several iterations, teams calculate their average velocity. For instance, team A might have a velocity of 6 story points per sprint, whereas team B is able to complete, on average, 8 story points per sprint. Having computed their velocities, teams can now plan their sprint targets more accurately.
Those who favor story points over time units do so for the two side benefits:
- increasing velocity – as the team gains experience, it has a tendency to complete tasks quicker, or burn more story points during an iteration,
- better predictability – story points estimations are typically “less wrong” than time units.
PROS of story points
- Story points make the estimation process easier and quicker than the use of time units. All a team needs to do is agree that feature A is, for instance, twice as complex as the model task was. No need to assign a specific number of hours, days or weeks.
- Story points mostly “fix” the over-optimism of those who estimate. They leave less room for underestimation of time, costs, and risks.
- Since story point estimations are so accurate, prioritizing task A over task B tends to be dependable and reliable; consequently, the organization outputs customer value “at full throttle”.
- Since money and time “are not an issue”, pressure is rarely exerted on the team. Loss in quality happens less frequently.
- Story points promote including risks in the estimates. With traditional time units – hours or days – people tend to beware of the management’s reaction and skip that 50% markup in case risks materialize.
- Story points are inherently inaccurate and imprecise. This way they address the problem of external communications and managing expectations beyond the development team.
- Story points are incompatible with the money and time units mindset, characteristic of management boards. On a related note, BigPicture can convert story points into hours and days; we have clients who consider this feature a profanity ;)
- People, in general, do not comprehend story points. The higher in corporate structures, the more this is true.
- The development team could lose touch with the market since story points do not address the clients’ questions, such as ‘When and for how much will I get the product?’
- Inter-team rivalry cannot happen, since the story point of team A does not compare to the story point of team B. Even if story points were comparable between teams, agile methodologies advise against motivation by comparison.
Could story points blow a budget?
Could it be that the product being developed never actually brings profit because of the “unlimited time and money” inherent in story points? There are some security features built into story points, and here they are:
- With story points, you need to budget, too (“How many iterations will the funding received last?”). When funds run out you need to re-apply for another tranche to the CFO or steering committee. This obviously promotes staying within the original budget. Another favorable factor is that agile methodologies do not provide for a fixed scope. A project might end with an MVP version of the product or because the funds have run out.
- The story-points-using teams tend to be well-motivated. The software industry itself, as well as software departments in other industries, attract geeks. Few people seek IT employment just for power or money. Damage to a firm’s reputation re-echos in the industry.
- Since all members of a team estimate collectively there is less room for subjective judgment and extreme underestimation. The story point estimates tend to be accurate.
Why do story points fail in some organizations?
Why do story points occasionally fail? What do organizations realize en route?
- You can’t automatically convert hourly estimates into story points estimates. Each task needs to be “manually” re-evaluated and re-estimated by the assigned team.
- The more ‘unknowns’ in your project the better chance story points will not work. “Terra incognita / unexplored territory” type of projects call for time units and not story points. The ‘to do’ work must overlap some past, ‘done’ project for the story points to engage.
Consider abandoning story points when you feel the estimations are “unnatural” or false.
With all that being said and with BigPicture capable of both story points and time units (including converting from one to the other), we believe that story points ARE actually hot.
More and more organizations abandon projects in favor of value streams (read more in Enterprise Agile Planning tool Q&A). Value streams, in turn, entail enterprise-level agility. With the top managers now planning agilely, one of the serious cons of story points disappears (“story points are incompatible with money and time units mindset, characteristic of management boards”). ‒Notably, hybrid portfolios (a mix of classic and agile projects) do not remove that con – remarks Jerzy Sekula, Product Owner at BigPicture.