What is a story? How big does it have to be?
The main issue is that some people think they need to define every little bit into infinite detail.
The epic user story I used to write was relatively small, including the required definitive tests to demonstrate that it was done.
The secondary is that delays cost money - however if you're only delivering "done" and being paid for that work then any delays should be part of the contract as a penalty. At the moment the client being slow is simply costing you money with idle fingers burning cash. That should be a penalty in your agreement. You may be able to substitute tasks but if the tasks aren't ready for a sprint then I would look at why? Perhaps a task to "define" in the backlog that means the engineer works with the customer to drive it - then you can point at the time it's taking directly with a define task with your customer.
Working as a set number of developers for a year is another way, but as a client I found that it doesn't incentivise the third party development company. It simply means whatever they do, and how badly they do it, they get paid.
If the client has to dovetail the agile process into a traditional process - then the way the requirements are being defined may need attention. Simply putting it all in a word document or DOORS may tick all the process boxes but it's not really delivering business value. Process for process sake.
The role of an engineer within agile/scrum is wider than "the monkey presses the button". Some development teams expect to be spoon fed all the details and put down tools until what's perfect is fully documented - this demonstrates a fundamental misunderstanding of agile. If anyone takes this approach with me they tend to feel very uncomfortable - their responsibility to get off their butts to drive the thing forward. If the customer is blocking that should be very visible to them..
Last edited:
