On an application development project I had problems with estimating the details of software projects and managing feature creep. We were tracking okay to the high level estimates we had put together pre project, but on a story by story there was very little accuracy in estimates.
As we know from Kailash's blog post delphi planning (e.g. planning poker) amplifies estimating capability. If your skills are good, the group approach makes it better. But if your skills are poor you'll just amplify your error rate. We seemed to be stuck in the second category.
Watching the cumulative flow and cycle times on stories gave me the right cues to take information to the plan with a recommendation. I could see the average story size was also the threshold for estimates breaking down. So, on average the effort to fulfil a story was going to vary substantially form the estimate. The threshold was a story of about 5-6 days of effort.
I put it to the teams that we target a 2 day maximum effort story size as a threshold, and if stories were larger we break them down further until they fit into that threshold. This was generally accepted (but not consistently applied.) The additional effort in breaking down stories increased flow and yielded improved results (which still needed further improvement.)
My role was in the analysis of the team’s performance data and linking the problem of large stories with size limits. The team were able to adopt this change and the positive results were shown in future performance reports.
This led to me generally advocating the “count the stories” mantra alongside the Kanban method community. I’ve also combined it with the Requirements Traceability technique to good effect. (see more here.)
0 comments:
Post a Comment