Counting points at developer done is a controversial topic. I recently engaged in this discussion with my team and we reached an interesting conclusion. The typical way to count points for a story is when the story has:
- Been completed by the developers
- QA, automated functional or acceptance tests are written and passing
- All outstanding bugs found by QA/client have been resolved and fixed
- The client has signed that story off as complete
It is only at this final stage that the points for the story are counted towards the team's velocity. In my team, we were counting the points at when the story was developer done. That is, we were counting points when the developer has just finished work on the story and hands it over to QA to be reviewed.
After much debate among the team we finally came to the conclusion (after some very wise words from a senior member of our team) that it didn't really matter.
Our attention was brought back to one of the purposes of counting points. One of the purposes of counting points is to communicate progress. If the client and team have a shared understanding of what is being used to quantify that progress and it is being quantified in a consistent manner - at developer done - then counting points at developer done is fine. The reason for this is that everyone is on the same page as to what it means when 10 points is added to the velocity, that is 10 developer done points. In our case, our client and us both knew we were counting points at developer done so we decided it wasn't a problem. However it came with a few other conditions.
We agreed that counting points at developer done is OK, provided that there are no extreme fluctuations in the amount of work that is required post developer done. This includes the effort spent through volleyball, the effort being spent by QA's to test and also the effort spent by developers fixing those QA found bugs. We decided that if there was a large fluctuation in that time, such that it begins to lean towards more work being done post developer done, then this sort of counting process should be reviewed. The reason for this is that there is going to be a large amount of effort being undertaken post the points of a story being counted done and this is going to have a large knock on effect in project planning. So with that decided, we continued counting points at developer done.
I have now posted a follow up article, aptly named Counting Points at Dev Done in Hindsight.
