Claiming Points (It's not Done until it's Done)

I recently came across a Scrum team that was working in what I felt was a bizarre manner. A manner that was undermining their credibility. The business was losing confidence in them, by association the other teams and Scrum in general.

So what was it they were doing that was having such an impact? On the face of it (to those that don't know), not a lot. They had replaced 'Done' with the concept of 'Dev Done'. In other words, once the development work had been completed and peer reviewed, the work was deemed complete, and the points claimed updating both Sprint and Product burn-up. The work was then 'thrown over the wall' to the QA's to test. they way they justified this to themselves was that they were then more efficient and could concentrate on clearing the backlog delivering those valuable features the business wanted. It was also claimed that the QA's were slowing them down.
Agreed, initially is looked like they were churning through the backlog very very nicely. Much faster than the other teams, but that was short lived.
After a couple of sprints, once they got to the less well defined work, the cracks started appearing. Some of the problems included:

• A high rework rate (That was not what we wanted)
• A high defect rate. (It works perfectly, but not what we wanted, Is it a defect?)
• Fragmentation of the team (Conflict between developers and QA)
• A breakdown in trust from the business
• A drastic drop on throughput

This was all because they stopped working as a team with collective responsibility for delivering those new valuable features. The developers stopped talking to the PO's and often misunderstood or ignored the business need. It was up to the QA's to gets the test completed and gain acceptance of the work from the PO's.

The result of this was:

• A lot of friction between the PO's & QA & QA and the developers
• Reluctant acceptance of features that did some of what was expected
• Delivery of a number of features that did not perform as expected and not really for for purpose
• Releases were a nightmare as QA often lagged the development by a sprint or more (average cycle time was over 9 days!)
• We were forever patching an earlier branch while working on a current one

It also meant that a large number of defects were raised, along with a new stories that did nothing other than re-work the work that had already been done, artificially increasing the size of the backlog wasting time and frustrating everybody.

All of this could easily have been avoided by taking collective responsibility for delivery, planning/conditioning properly and having those early conversations with the PO's during the sprint. Find out what you need to do before you do it, show it early to make sure you are on the right track, save on defects and rework.

The fact that the developers were external to the organisation while QA's were mostly in-house as were the PO's, did have a big hand in creating this situation, but it could have easily been resolved long before it became a problem.

Key things to take from this are:

• Stay true to the Scrum principles
• Take collective responsibility
• Talk and talk often
• The 3 C's (Card, conversation, confirmation)