Why we don’t count incomplete stories


It is the end of the sprint. This has been a fairly good one, we had set to complete several user stories among them the following:

  • As a customer, I want to be able to manage my notification frequency
  • As a merchant, I want to be able to quickly see what time my customers like receiving information from me
  • As a merchant, I want to be able to alert customers of new product offerings

To each of this stories, you had given an estimate of 13 story points. You have managed to completely deliver on the first and last item. For the second one thou, you are not quite done. While the API is ready, the feature is not all wired up yet. You feel like you are about 90% done. But the sprint is over so some work has to roll over to the next sprint. Do you assign it’s 13 points to this sprint or the next? Or maybe you assign 90% of the points to this sprint and 10% to the next?

This is a scenario that often gets played out in development shops everywhere. My simple answer would be, don’t assign any points to this sprint. In fact, don’t assign points until the story is fully complete.

Here is why.

The incomplete space is virtually infinite

It is easy to understand when I say the feature is complete or not complete. The space in between can mean almost anything. Here are some examples:

  • Can mean not coded but tests written
  • Code has been written but no tests
  • Currently being refactored

Thus my opinion of 90% done and yours may be dramatically different. I may mean that am yet to push changes to the server. You may be an advocate of measure twice, cut once and thus are now just done with the design and starting out with the code.

It’s much easier to just take a binary stance.

Feedback times increase

A key principle of Kanban is to limit work in progress

In software, this matters because work in progress increases feedback time.

Cycle time = Weeks / Feature

Let us combine that with Little’s Law

Average wait time = No of features in progress / features completed per week 
Average wait time =  No of features in progress * Cycle time

From the above, we can see that each incomplete feature increases wait time by a cycle.

With increasing WIP we get increased time to feedback. This is a vicious cycle. Eventually, you kill off all benefits that would have been accrued from the faster learning granted by agile.

Trust is lost

Agile runs on trust. The development team trusts the client to communicate the problem, give truthful deadlines and appropriate priorities. The client expects the developers to give them estimates that are correct and to deliver the best possible work that they can.

In fact listed in Values of extreme programming is the virtue of courage:

    Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes when ever they happen.

Immediately the development team discovers that the feature can not be completed in this sprint, it behoves them to start a conversation with the client. Perhaps the story can be broken down and part of it moved back to the backlog? Or with this new information, the client can decide to simply de-prioritize the entire feature from the sprint.

Either way, by involving the client in the discussion, a much more holistic solution can be found.

How do you manage incomplete stories in your own agency? Talk to me in the comment section below or on my twitter @jchex


Published by


API Engineer