Scrum Principle : Backlog work can come from many sources, but only one person prioritizes it.

Once upon a time there was a software release that couldn’t seem to get to the customer site. It was too buggy, the customers said. And these were beta customers, who should have been willing to accept less than perfect code.

The development team had been toiling for nearly a year, cleaning up one bug after another. And the list didn’t seem to get smaller. Instead, the list was about the same size. The morale of the team was not good.

Although Scrum didn’t seem at first glance to be directly applicable to this situation, we instituted daily Scrum meetings. Daily Scrum meetings are the thermometer into a chaotic situation, providing a daily view into the dynamics, morale, progress, and overall situation of a work effort.

As we went around the team during the first week, we noticed that a number of developers were working on what could best be termed "enhancements". Because the release had been so long in getting out, marketing and the product managers were introducing functional enhancements into the mix. These weren’t visible previously, but in the daily Scrum meeting it became obvious that the enhancements were consuming a lot of effort, and introducing bugs throughout the product.

We checked, and there was a bug/incident tracking system, called "BIT". BIT aged incidents by priority, and allowed bugs and incidents to be entered by both customers and internal staff. Management reports were generated from BIT. Studying the management reports for the last several months, the number of bugs and incidents had risen about 10% per month to the current approximately 520 incidents.

We developed a policy that all functional enhancements would be entered into Scrum backlog and wouldn’t be part of this release effort. We also developed a policy that the developer’s would only work on items on BIT, starting with top the most severe priority.

Once the policies were in place, all developers were working on bugs and incidents that were in the way of the product being released. We noticed the outstanding bugs and incidents drop rather than stay steady. However, during the daily Scrum, we now noticed that some of the developers were working on what appeared to be cosmetic issues, whereas others were grappling with tough, product crashing bugs.

We discovered that the person (customer or employee) who entered the bug onto BIT got to choose its priority. The color of fields was critical to some customers. We immediately had the priority field made secure and appointed one product manager whose job was to triage the incoming bugs and incidents, giving them priority based on the real criticality, where criticality was defined as the degree to which that bug or incident stopped the product from being stable at a customer site. Stability was the key indicator.

We divided the BIT list into items that were critical to product stability, and all others. We met with the customers and reached agreement that product release was dependent only on correction of stability issues, and that all other issues would be addressed – based on their priority compared to new features – in future releases.

After one month, the number of issues that had to be resolved prior to release had dropped from over 500 to less than 200. Monitoring what the development team was doing on a daily basis made this happen, letting us focus them on only the work that mattered and stopping external parties from introducing new work.

The rest of the daily Scrum process aided work completion, also. As one person reported the bug that was confounding him, another developer remembered similar problems and met with that person after the Scrum meeting. When particularly sticky bugs persisted, we were able to bring in outside help and focus efforts to resolve them.

Most important, the development team no longer felt in a morass, and was no longer viewed as inept. They were making clear progress toward producing a releasable product. After three months, the product was released, customers satisfied that the company could build and release software, and the team was free for working on the next release – based on the full Scrum process and a prioritized backlog list.