Thursday, November 19, 2009

Opt-in from a Trial to a Paid Subscription

Yes, we have listened to our users. Now your 30-day free trial subscription will not be automatically converted into a paid subscription at the end of the trail period. Although we send an email notification a week before a trail period comes to an end, it seems users may not act proactively to cancel their trail subscription. It was never our intention to mislead our esteemed users to signup for a trail subscription only to convert them into a paid one. We wanted this to be a convenient feature, should anyone decide to continue to use ScrumPad. They can continue to use the service and keep their data. However, we realize that how people can forget to cancel subscription in time and then be surprised later when they receive an invoice. We never require anyone to pay for a service that they did not use. In fact, we do not take our customer's credit card info and do not charge customers' CC automatically when payment is due. We only invoice at the end of the month after our customer used our service for the month. Customer has the option to pay or ask for waiver because they are not happy with the service that month.

So, from now on you can upgrade to a paid account anytime during your 30-day free trail period. Or, your trial account will automatically be suspended after the trail period. If you try to login after the trial has expired, you (account admin) would be prompted to explicitly agree to upgrade to a paid account. Once you agree to upgrade, you can continue to use your original account without loosing any data. You will still receive an email reminder one week before your trial account expires.

We are happy to be able to make this change. We hope there will be no confused users either.

Wednesday, November 11, 2009

Should fixing bugs contribute to a team's velocity?

I get this questions often. I am sure you probably also got this question at one time or the other. There are two ways to look at this- value vs. cost. These perspectives are linked to how you define velocity. Let's look at both in more details.

Value perspective. If you define velocity as the net value (in story points) delivered to your customer, then you should not include bugs in your calculation of velocity. Think about it for a moment. Bugs are something that are not working as expected, but the customer has already paid for them. So, by fixing bugs you are not really delivering any "incremental value" to the customer. If you increase your velocity by including bugs, you are inflating your velocity. Now, granted that sometimes we report something as a bug when it is an incremental feature. You need to work with your product owner to negotiate to change those bugs into stories and account your effort for them in your velocity.

Cost perspective.
If you define your velocity as the amount of work done by a team in a sprint, then you should include bugs in calculating velocity. Yes, bugs take effort and time to fix. Hence there is a cost associated with fixing bugs. But this makes the release planning a little bit complicated. Because you cannot know ahead of time how many bugs you may have until the release. Directly using velocity to calculate the effort or to determine the time-line for the release will most likely be off (undershoot). One way to address this is to break the velocity into two components- feature-delivery velocity, and bug-fix velocity. This is in a way going back to the first option.

I personally am in favor of using "value" perspective and exclude bugs from calculating velocity. This helps keep our eyes on the ball- delivering "customer value." As a result, we are encouraged to reduce bugs in the first place so that we can free up our capacity to deliver more value. That is why we currently do not allow users to point estimate bugs in ScrumPad.

Are you including your effort spent on bug fixing in your velocity?