Is it good enough?

How many times do we ask ourselves this question? what is good enough? others might call it - what is the minimum? what is 'potentially shippable'?

The thing is, that if you put 10 people in the room and ask them this question, you will get 10 different answers. Its all about perception. Usually (but not always), developers will be fine with releasing a product with 'half' features while UX people will think it is crazy. I believe that in order to be able to answer this question, you should first as yourself these ones:

1. If I am releasing this 'half' feature, will that feel like a bug or a missing functionality?
2. Will the customers be more happy with the part they got then frustrated with the missing part?
3. Will I be able to get some valuable feedback from the field on if/how to continue developing this feature once I release this 'half' feature?

You need to answer yourself these questions honestly and be willing to let go on the 'complete feature' attitude that used to be much more relevant in the days of waterfall when we released a version once a year and not once a month.

The way to accomplish just that is to develop the product in the new 'layers'. You deliver the 'minimum must' of each 'must' feature and you incrementally improve those in the next versions. You might find out that you will stop developing some of them as they are not that useful to customers as you originally thought. That is the beauty of it. You are making sure that developers are always working on the most important stuff.

One more thing to remember. The answers to the questions above will probably be affected from the maturity of the market. Let me try and explain: imagine I would come to people 60 years ago and suggest them a machine that will wash their dishes. This machine will have an on/off switch, a place to fill in water and soap (no water pipe), and a designated bucket for the dirty water which you will have to take out and empty at the end. But hey, you wont need to wash them your self ;) I am guessing people would buy it (at least some). However, if I suggest them the same today - people will kick me out of the room. This is what I mean when I am talking about maturity. You have to be realistic and look at the market.

But before all the tough questions, the first step is to break a big feature into small pieces. I mean, the smallest ones. Then, group several of the pieces as a phase/step of a shippable part of the feature. Remember, the way to do it is to answer the questions above. Make sure you are not grouping ALL of the pieces together, in most cases, you shouldn't.

Lets look at some examples:

1. New 'campaigns' management grid
1. Display grid with the columns: Name, Conversion rate, ROI, Cost
2. Create campaign
3. Delete campaign
4. Copy campaign
5. Edit campaign
6. Pause campaign
7. Sort table
8. Filter table
9. Select columns
10. Add columns: Statistics, Creation date, Start date, End Date
11. View Ads

How would you break it? let me try and do it:

1. Phase 1:
1. Display grid with the columns: Name, Conversion rate, ROI, Cost
2. Create campaign
3. Delete campaign
2. Phase 2:
1. Edit campaign
2. Pause campaign
3. Phase 3:
1. View Ads
2. Sort table
3. Filter table
4. Phase 4:
1. Select columns
2. Add columns: Statistics, Creation date, Start date, End Date
1. Copy campaign

For each and every phase I will ask myself the three questions above. If I am not happy with the answers I get, I will adjust it again. This is the process of splitting features to deliveries. Always compare the next phase importance against another feature's phase. Do not look at it as one block. Make sure your priorities are cross features and be honest.

Keep in mind that you may never get to develop phase 4. That's fine. It means that you had something more important to develop. It means that you are always developing the most important thing and that is what you wanted to accomplish. Everything is important, the real question is what is MORE important then what. When you have a tough priority question - ask yourself what you can leave without.

The question 'is it good enough?' should be always answered with respect to:

1. The answers to the questions above
2. The importance of other stories in your backlog

I believe this is the way to really utilize the agile development to the benefit of the customer. Good luck!