There is always a dichotomy between theory and practice (or is there for most teams). One of the prime examples that I have seen in several Scrum teams is about this concept of the end product of each Sprint cycle fitting a term called being ‘potentially shippable’. During the training, and the literature, and articles all mention that at the end of each Sprint, the concept should be that you could pick up the product that has been completed, and ship it to the customer. Whoa, I can hear some scream. How can that be ? We would finally be ready to ship at the correct time of the schedule, not before. We know that we all discuss the concept of the product being apparently ready to ship at the end of a Sprint cycle, but that just means that the quality should be good; we cannot ship it as of that time. And there can be plenty of arguments given for these which seem sound – only part of the design has been completed, some important customer features not yet complete, there are still many critical defects present in the application, and so on.
So, I spoke on this to some Scrum experts, and they are unanimous on this. The concept is what you need to attain – at the end of every Sprint cycle, you should be able to take the product and ship it to your customer. As to some of the objections:
– If your product still has important defects in it at the end of the Sprint cycle, obviously the feature so included is not ready to ship, and should be dropped from the Sprint cycle and taken forward for the next Sprint
– If there is a need to ship this product to the customer ahead of the desired ship date, then obviously, it would mean that there would have been a discussion with the customer that some features would not make it, that the design so done in the less than expected time would not be complete. If the customer has an emergency, you better be ready with the product (in a specific case, the customer urgently needed the product to show to some investors who were losing patience, and the product delivery at 1/3rd of the expected schedule time (with no critical defects, but with not all the features present) did a lot to reassure the investors of the client).
– Features need to be included in Sprint cycles based on their importance, so as time progresses, the remaining features are the less important ones. If some of the more important features have been left pending while other no so important features have been incorporated, there is some problem with the prioritization of the features and the team should look at that. There may be legitimate reasons in terms of priority and order in which features can be implemented, but reviewing the process is something that should be carried out at periodic intervals.
– If your customers know that you have implemented Scrum and ask you for the product at the end of the Sprint cycle, you should not be ashamed of the product you are going to deliver to them.
Once the team gets into the habit of ensuring that the product is ship ready at the end of every Sprint Cycle, it will not be a problem and may help in streamlining of the entire process.
Scrum: Potentially shippable at Sprint end ? Truly ?
↧
↧
