White Wizard @ Leavewizard.com | Continuous improvement catalyst | Agile, LeanStartUp, Kanban, SystemsThinking & Stewardship
Friday, 30 October 2009
CSM course in Bournemouth 23 & 24 November
Geoff Watts will be holding a CSM training course in Bournemouth on the 23/11/2009 and 24/11/2009. For full details see here
Tuesday, 13 October 2009
Scrum and Agile metrics follow up
While looking at metrics and what is appropriate I finally came across something that made sense to me and to the scrum masters in our department.
The information is from an article by Michael James which doesn't seem to be available any more unfortunately. The title of the article is An Agile ApproAch to “Metrics” and you may try to find it if you're more persistent than myself.
This article suggests to use a combination of 3 or 4 metrics. While I generally like the idea I am not sure all of them would work in our current environment. For example I would avoid using velocity in that sense although I would use it as a trend and not really related to the reports that Senior Management wants to do.
The two things that I reckon make sense are:
1. Delivered business value - i.e. every item has a business value and you count how much is being delivered
2. Running Tested Features which is something Ron Jeffries talks a lot about and we happen to do - e.g. a feature is RTF if it can be demoed from production build and passes automated tests (which should cover the acceptance criteria).
These two in combination make it difficult to game and also guarantee both business value and quality. While I am sure some people can still game them, I believe they represent a reasonable way to resolve the metrics problem.
The information is from an article by Michael James which doesn't seem to be available any more unfortunately. The title of the article is An Agile ApproAch to “Metrics” and you may try to find it if you're more persistent than myself.
This article suggests to use a combination of 3 or 4 metrics. While I generally like the idea I am not sure all of them would work in our current environment. For example I would avoid using velocity in that sense although I would use it as a trend and not really related to the reports that Senior Management wants to do.
The two things that I reckon make sense are:
1. Delivered business value - i.e. every item has a business value and you count how much is being delivered
2. Running Tested Features which is something Ron Jeffries talks a lot about and we happen to do - e.g. a feature is RTF if it can be demoed from production build and passes automated tests (which should cover the acceptance criteria).
These two in combination make it difficult to game and also guarantee both business value and quality. While I am sure some people can still game them, I believe they represent a reasonable way to resolve the metrics problem.
Subscribe to:
Posts (Atom)