Loading Profile...
Recent activity
Subscribe to this feed
Jon Dahl marked one of Nathaniel Talbott's replies in Spreedly as useful. Nathaniel Talbott replied to the question "Can Spreedly handle variable charges?".
-
Jon Dahl replied on October 16, 2009 16:45 to the question "Can Spreedly handle variable charges?" in Spreedly:
Thanks! Looking forward to it. -
Jon Dahl started following the question "Does a user need to enter in their credit card info to upgrade plans?" in Spreedly.
-
Jon Dahl marked one of Nathaniel Talbott's replies in Spreedly as useful. Nathaniel Talbott replied to the idea "If it weren't for that $19/month fee...".
-
Jon Dahl asked a question in Spreedly on October 16, 2009 15:07:
Can Spreedly handle variable charges?Does Spreedly support variable monthly charges? Let's say we want to charge $10/month for the first 10 GB, plus $1/month for each additional GB. We want this variable monthly charge to be automatic (i.e. not submitted new each month by the user). Can Spreedly help with this? If not, are there any alternatives you would suggest? -
Jon Dahl marked one of Nathaniel Talbott's replies in Spreedly as useful. Nathaniel Talbott replied to the question "When will you guys support customizing subscription pages?".
-
Jon Dahl started following the question "What to do with "invalid" bug reports?" in Pivotal Labs.
-
A comment on the idea "Calculate velocity based on delivery, not acceptance" in Pivotal Labs:
This is a great compromise. If a story is rejected, it doesn't falsely inflate an iteration's velocity. – Jon Dahl, on February 23, 2009 15:22 -
Lawrence Sinclair's reply to "Calculate velocity based on delivery, not acceptance" was just promoted to the most useful! Jon Dahl and 4 other people think it's one of the best replies.
Velocity should measure the rate at which developers can produce business accepted features. There might be another metric one could keep track of that measures how effective the business is at getting around to evaluating work and how good developers are at getting the business to provide feedback in a timely manner, but adding this time to the velocity figure dilutes the core metric. In fact the core velocity metric becomes known to be biased, but not biased in any consistent fashion, and so become effectively useless. Currently, the only time velocity is meaningful is when one knows for sure that the business was always quick and complete in their feedback.
I think both Dan's concerns and Jon's idea are accomodated by using the delivery date, but *only* after the work has been accepted. This means that historical velocity may get updated as feedback from the business comes in over time. In some cases, we might not find out that something was done properly until the next week. But at least when one looks at velocity over time, one knows that it reflects true performance.
The alternative is that whenever the business is pre-occupied and can not provide timely feedback, developer velocity for that iteration becomes meaningless, and looks very low. And then future velocity measures will be meaningless and overstated when business catches up with their feedback. And since there is no way to know if this sort of bias is taking place, all velocity measurements lose credibility unless the person viewing it knows if the business was on the ball at the time or not.
By using the date of delivery for recording points once they are accepted by the business you get two types of reliability benefits: (1) historical velocity can be trusted, and (2) recent velocity is more reliable since we know it will not be overestimated (by including points from work done long ago). -
jondahl shared an idea in Pivotal Labs on February 18, 2009 15:33:
Calculate velocity based on delivery, not acceptanceI'd really like the option to track velocity based on the date that a feature is delivered, not accepted. As I understand it, velocity is a measure of a team's productivity, not a measure of a product owner's diligence in accepting features. If a product owner doesn't accept features on a predictable schedule, velocity calculations don't work as well as they should. -
Jon Dahl started following the question "Velocity calculation is a lie (sort of)!" in Pivotal Labs.
-
jondahl started following the idea "Tracker should have a single story view to make link sharing more efficient" in Pivotal Labs.
-
jondahl started following the question "Autolink to stories in description by ID using #12345 formatting." in Pivotal Labs.
-
jondahl started following the idea "Allow better internal story linking in Pivotal interface" in Pivotal Labs.
-
jondahl started following the idea "Offer private messaging capabilities" in Get Satisfaction.
-
jondahl started following the idea "Offer a private version of Get Satisfaction" in Get Satisfaction.
-
jondahl started following the idea "Quick access to ID numbers" in Pivotal Labs.
-
jondahl replied on January 12, 2009 18:05 to the idea "Integrate QA into stories and notifications" in Pivotal Labs:
I agree.
Pivotal, do you have dedicated QA staff, and if so, how do they use the tool? -
jondahl marked one of mattemge's replies in Pivotal Labs as useful. mattemge replied to the idea "Integrate QA into stories and notifications".
-
jondahl started following the idea "Integrate QA into stories and notifications" in Pivotal Labs.
| next » « previous |
