37signals have got their heads screwed on the right way. Over on their Signal vs. Noise blog Jason has posted about why they have many 'features' missing. His response: "It just doesn't matter".
Their latest product is "easy group chat for business" called Campfire. It's a web-based IRC-type service which allows you to chat, share files and pictures. They have left a large number of so called 'features' out and many people have been asking why on their forum.
They take the view that if it's not essential for the service to operate correctly then you have to make the hard decision of whether to include it or not. Any feature no matter how small costs, whether in time, complexity of the resulting code or in the usability of the final product.
When you are designing software for someone other than yourself how do you take the same approach? If they are paying the wages then surely what they want wins? My thoughts at the moment revolve around splitting out the 'non-essential' requirements into separate stories and estimating those individually. Then you can explain the cost of that requirement to the customer to see if they still really want it now that there is a concrete cost associated.
Anyone else got any other ideas?
Technorati Tags: Agile, Software Development, 37signals, Andrew Beacock
Their latest product is "easy group chat for business" called Campfire. It's a web-based IRC-type service which allows you to chat, share files and pictures. They have left a large number of so called 'features' out and many people have been asking why on their forum.
They take the view that if it's not essential for the service to operate correctly then you have to make the hard decision of whether to include it or not. Any feature no matter how small costs, whether in time, complexity of the resulting code or in the usability of the final product.
When you are designing software for someone other than yourself how do you take the same approach? If they are paying the wages then surely what they want wins? My thoughts at the moment revolve around splitting out the 'non-essential' requirements into separate stories and estimating those individually. Then you can explain the cost of that requirement to the customer to see if they still really want it now that there is a concrete cost associated.
Anyone else got any other ideas?
Technorati Tags: Agile, Software Development, 37signals, Andrew Beacock
Comments
The point is that the cost stays the same if it's 10 stories or 1. But splitting the work into smaller components allows the customer to be more flexible in their choices.