In the world of agile software engineering, the keyword is agility. Stories for example aren’t called out in the agile manifest
. In reality, little is called out specifically in the manifest, apart from the need for collaboration and working software
In the world of corporate scrum, many firms at the management level want to track story actuals, thus venturing down the road of comparing estimates vs actuals start, and then the inevitable story size of points vs hours. I wonder if the amount of effort involved in estimation couldn’t be better used in delivering more stories that themselves are delivering business value as a measure of the return on investment.
More recently we’ve had the discussion on no estimates
, which in some quarters works well, since the trust between business and technology teams is high. Trust being the keyword here, coupled with more than likely leveraging Kanban over scrum as a lean process to deliver business value.
This nicely brings us to gamification
. Gamification has accelerated in the last few years in many different area. However, I’ve not seen is used much in software engineering, other than the unofficial Excel sheets of bugs, releases and such.
My proposal is therefore the following, which is more suited to Kanban, but at the end of the day can be tuned to whatever software development process you are following:
- Ensure you have an ordered backlog of business value stories that have A/C, adhere to a sensible story format.
- Drop estimation
- Engineers get 20? points for completing a story (Done).
- A Done stories that has defects raised before moving to production, loose a point per defect
- Whether you have an automated Continuous Deployment process or manual process, the team member who performed the release to production gets 5 points.
- Testers get 10? points per defect
- Put in place a team wide scoreboard
- Each month, the greatest scorer get some small prize e.g. voucher etc
- Retrospect on the above and improve e.g. maybe the business assign business value points to stories to enhance the ordered backlog?
Net out, you’d hope that velocity has improved, and defects have dropped. Which at the end of the day is what we all want, whether we are management or software engineers, we want to know we are making a difference, and delivering value.