| When I created this graph I was looking at historical data that existed before I got involved with the company, so I don't know the complete story on all of its details... But it's important to note that this is an accumulation graph... so it starts at zero but that doesn't mean a backlog of zero (my guess is it was massive, because it was massive at the time I arrived)... this instead counts issues opened and closed during the time period across the entire system. Some issues closed during this period would be ones that were opened long before the start of the period. This means that the graph will always increase, and that the space between the two lines represents the growing net increase of unresolved issues in the tracker. I wish I still had the raw data on this, because it's a little hard to tell from the scale that the differences from week-to-week can be pretty big (like 10 issues opened one week, 50+ another) When I arrived, there were a few specific issues in play, along with all the usual code quality / project management issues that plague any troubled project: (1) A high number of support requests that required manual setup work from developers, which increased greatly due to overall growth in the customer base. (2) Some high defect density areas in the codebase that generated emergencies, and fixes that would end up breaking other things in the process of dealing with the acute issue, along w. infrastructure/architectural scaling problems. (3) As you guessed, reduction and restructuring of team capacity, without a corresponding change in the workload. So these things... they happen more often when we wish in the software industry, and it produces graphs like this. (that said, keep in mind this was pretty much a napkin sketch. any issue tracker is going to have a TON of noise, unless it's very well pruned -- the sole purpose was to point out the wide gulf and relate it to the problems already obviously observable onsite, and then use that to motivate real work to change things.) |