Plans are afoot from product management to start adding subjective value to requests (release plan) and raised defects.
When a story closes the customer rates the value it delivered and updates the overal status of the value delivered as they see it i.e. (+/-/none). This (the theory goes) will allow us to plot value and stop developers concentrating on burn-down’s and prioritize valuable items over non-valuable. It will also allow us to schedule clumps of “minor” defects over stories, because the value of fixing the defects will exceed a given story (polishing in disguise and a replacement for team improvement?).
I look forward to seeing how this pans out, but feel people have missed the point about Agile and are taping even more stuff around a simple system which takes active communication and participation over “long distance” metrics. I do think developers should have an understanding of business/commercial value, but the Agile process has at its centre an active customer who physically drives the backlog, the next story is the next most valuable item (defects = stories)? This feels like a proxy for the customer and a means to see the distance between them and the development team. “This is of no value”, “why did you accept the story”, “I didn’t” – Hmm, stories have lost their value?
Don’t get me wrong, I encourage experimentation and I really hope this pans out. Worry its not really been thought through…
I have been thinking about a project management tool whose database could be placed under an SCM and therefore branch with projects, allow good history control etc. Someone at work sent me a link to ditz, it looks promising, will play with it at some point.
As the person who sent me the link pointed out, it suffers (we think) when assigning unique identifiers to defects/stories – In a decentralized environment how do you get the next unique ID, without falling back to GUID’s which are fine for machines but not humans? I will need to look at in detail, maybe they have solved this?
Possibly all I need is git and ditz (rather than git + redmine) and drop the requirement for fancy GUI based input.
Although the system I initially imagined would have a ruby on rails application, using WEBrick. The web application could be fired up, run locally and provide a GUI based means to edit the project. To be honest it could be any form of visual editor but platform agnostic. I liked the web based front end as it would conceptually allow non-technical people to manage the project.
