Loading Profile...
Calculate velocity based on delivery, not acceptance
I'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.
I’m happy
8
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company has not planned to implement this.
The best point from everyone
-
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).
I’m in disagreement
5 people think
this is one of the best points
-
Inappropriate?It's a great idea, so the development team may select the calc base (deliver, accept, finish...) -
Inappropriate?Hi Jon...thanks for the idea. We're considering adding the ability to customize the default story workflow, for example to add QA-related steps, but calculating velocity based on accepted stories is actually pretty central to Tracker's core philosophy.
Velocity is calculated based on accepted stories only, in other words, it doesn't consider a feature as complete until it has been seen and verified by the project's customer or product owner. This is a key ingredient of most customer-driven agile methodologies, including Extreme Programming, the method that Tracker's story workflow is based on. Story acceptance commonly leads to the discovery of missing or misunderstood requirements. Without this constant feedback loop, your project risks accumulating a lot of unexpected work, or worse, gradually moving off-course. Unfortunately, this usually doesn't become obvious until you get close to a release, at which point the cost of incorporating product owner feedback becomes prohibitively expensive.
It can certainly be a challenge to make sure that the product owner accepts stories on a timely basis. As long as there is a consistent rhythm, though, it's ok if stories get accepted in a subsequent iteration - over time, velocity will take that into account. -
Inappropriate?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).
I’m in disagreement
5 people think
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
This is a great compromise. If a story is rejected, it doesn't falsely inflate an iteration's velocity. -
Inappropriate?I just noticed a way to hack a solution to this problem with Tracker's velocity calculations.
After a story has been accepted, it moves into the Done queue with the option to specify the date it was accepted. You could just manually change the date to the point when the story was submitted for review by the business. The big remaining problem is that the date when the story was implemented is not recorded, so the business still needs to guess what the correct date should be.
It would be really nice if Pivotal just recorded this date in the story notes. However, a simple solution would be to just ask developers to add a simple comment such as "done" just before submitting a story for acceptance by the business. The comment will appear persistently with a timestamp, and the business should just go into the Done queue and change the acceptance date to the date in the "done" comment's timestamp.
One problem with this, that I suspect will be the case, is that past velocity will probably not be updated by Tracker when you push an accepted story into a past iteration using the method described above. However, at least you won't overinflate current velocity by having past iterations' completed work appear in the current iterations velocity.
I’m pleased with myself
1 person thinks
this is one of the best points
3 Comments Add a comment
This is one of the best points
-
Back dating an accepted story into a previous iteration does update the velocity.
Ideally you should try to get the feedback loop tighter so that acceptance happens as soon as possible after delivery. But in those cases where you are working under non-ideal circumstances, back dating the acceptance is probably your best bet for accurate velocity. -
I thought that Pivotal did keep track of the date of implementation. It's in the history for "Delivered". So no need for additional info if you want to backdate
-
yes - this is exactly the work around I've been using. I agree with Jon that accepted story velocity points need to be applied to the iteration in which the story was delivered.
EMPLOYEE
