Expedited Stories

I mentioned in my No More Iterations post that we didn't really know how support requests were going to affect the overall system. As is often the case I didn't have to wait long to find out.

Within days of moving to the limited WIP approach we got a raft of support requests, several of which turned into "must fix now" types of issues. Since we had just switched, we absolutely didn't have a slot on the board (in fact we had 13 stories for a 6 slot WIP).

Since these urgent requests had to be completed "right now" we decided to go with an "expedited story" concept. An expedited story essentially trumps all other backlog and work in process (WIP) and jumps to the head of the line stomping willy-nilly all over the other in-flight stories.

Obviously we don't want to have a lot of expedited stories so we discussed having a special slot just for expedited stories that would remain empty most of the time, but would also restrict the amount of thrashing the team would experience. However, based on my experience urgent requests tend to come in waves, and telling the business that our process doesn't allow us to help more that one customer at a time is professional suicide. What we are doing is examining all the urgent requests to see if they are truly urgent, or if they could wait a few days. If they can wait we put them on the backlog and process them normally.

To help us understand what is going on over time we are going to track the number of expedited vs. normal stories as well as doing some root cause analysis so we can prevent as many expedited stories as possible in the future.


1 Comment

  • We have identified a bottleneck in our ability to test features we have developed. We are taking a 3 pronged approach to relieving this bottleneck:

    1) Have the developers help with testing (short term)
    2) Hire an additional Tester (medium term)
    3) Develop more test automation (long term)

Comments have been disabled for this content.