I can’t resize the run even if is straight uphill both ways!

The question of resizing a story has many variations based on the rationale the asker is using. Rationales include stories:

  • that the work is harder,
  • take longer,
  • for which someone else is going to do the work, or
  • on which people missed the boat entirely.

If the answer given is no, the immediate next question is often “If not, then when does it make sense?”  Let’s start with the easy part of the answer.

There are two basic scenarios calling for reshaping and resizing. Both cases represent a failure of the team’s understanding of the piece of work.

  1. The story is actually a feature or epic.  Teams should never take a work item into a sprint or iteration that isn’t complete-able in that time frame.
  2. If the story, when the team gets into the nitty-gritty, is not materially what they originally thought, then reshape and resize the story. An example of getting it wrong is thinking you were building a bicycle only to find out you are being asked to build a car.

There very few other reasons for resizing a story.

The underlying basis for the question is an estimation and generally a mistaken conflation between story points and effort.  Story points reflect the perception of the team’s understanding of how complex and the amount of work required compared to other units of work. Planning story points nearly always devolves into planning hours.  Therefore, when asked whether it is OK to resize a story generally what is being said is . . . can we change the effort estimate for this story?


The size of the work needs to be tied to a less transitory attribute than effort.  The effort represents many factors, including the size of the functionality, the technical or business complexity, and who is doing the work. Logging into WordPress to write this blog represents a small piece of functionality (from a user’s perspective). Logging on to the system has little business complexity while it might have some interesting technical complexity due to security requirements — the complexity of the basic application is generally understood by the team doing the work. The major variables in the effort equation are almost always the experience and expertise of the people coding and testing. Experience and expertise don’t impact size, a 1,400 square foot house is 1,400 square feet regardless of who is building, they affect EFFORT.

Teams effectively re-estimate without changing the number of story points using two tactics (assuming they don’t run into the two good reasons to change the story points).

  • As teams break out tasks, they change the effort estimates (often in hours).  By the time the story is completed the tasks include the effort history for the story. We will circle back on the usefulness of estimating tasks and tracking effort when you are not billing for time.  The story points are not amended.
  • The team completes the story as quickly and efficiently as possible.  The team reaches the definition of done when they are done and do not change the story point size. Over time the average velocity (story points completed divided by the number of sprints) tracks what the team can deliver. Story point driven velocity, as a planning tool, evolves as the team’s expertise and experience changes.

Resizing is a bad idea, it wastes time and effort that would be better leveraged developing and delivering functionality. If you are using velocity as a planning tool (throughput is better) velocity needs to reflect your initial understanding because that is what you will have during planning.  How fast you complete the work will change as experience and expertise changes. If you really did not understand the work you were committing to do, I would rather spend the time figuring out how to avoid that problem rather than how to manipulate velocity.