Re: [scrumdevelopment] Help! Srum for Contract Based SW Development
- Call it paranoid or intent out of the 5 projects that i have been part of in the last year at least 3 projects had the so called bugs in the bug list. To counter this (since this tends to happen a lot) we have a very tight documentation process setup. Every communication (Emails, Voice conference, IM Chats, Personal chat over the phone) with the client/PO is well recorded and the Team Leader is directly responsible for it. Also all communication is channelled through a single point so that keeping track of it is possible. This way the billable and non-billable work can be seperated along with the bug fixes and so called bug fixes.
When talking about bug fixes, we tend to get quite a number of projects which are solely for bug-fixes. So we have to take in the code and design done by some other group and fix bugs in it. How can we create the product backlog and sprint backlog for these kinds of projects. Currently we ask the PO to provide a list of fixes they want and then start the fix from the end where it's the easiest to understand the system or is the most visible part. Any thoughts on this (It's surprising how many such projects are there out there)
Bob (Vaibhaw Poddar) http://hither2forlorn.blogspot.com :To a kid with a hammer: :Everything looks like a Nail:
Hubert Smits wrote:
If you leave the suspicion out of your remark, i.e. the customer will
pay for 'bug-fixes' (let's call 'm changes). Would that not lead to
On 4/25/05, Ron Jeffries <ronjeffries@...> wrote:
> On Monday, April 25, 2005, at 7:33:26 AM, David H. wrote:
> > Still such a proxy Owner has to be in tight contact with the actual
> > Product Owner. Since the Product Owner really refuses to supply that
> > feedback, you will have a problem sooner or later. I am speaking from
> > my own experience here :)
> Yes. We have already heard that the customers provide thin specs at
> the beginning and then ask for changes as bug fixes. This may be due
> to ignorance, but someone more paranoid than I might think it was
> part of a negotiating ploy:
> Provide a thin spec; get a low price on a fixed-price contract,
> with free bug fixes; provide the real spec as bug reports.
> I don't see any good way to proceed without a good spec, whether
> doing Scrum or any other process.
> Ron Jeffries
> Improvement stops when we start believing that
> ideas about how to improve are insulting.
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
> Yahoo! Groups Links
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...