Lawrence Sinclair's dashboard

I get it. Cool.

I think it would remain important to present both a project velocity and a team velocity. Each has a different audience. A project manager/client will be interested in just their project's velocity. But a higher level manager will want to look at how their organization and team members are performing.

The problem with looking at velocity for a team is that team members can (and should) swap around. This means one needs to allocate velocity down to the individual developer level. This is the only constant.

This makes me think of the idea of synthetic or hypothetical team velocities. I'll post that separately.

An important, larger point, is that I have heard credible people suggest that teams should NOT be spread out over multiple simultaneous projects. Sometimes there is no choice. But it is sub-optimal. It is hard for people to stay focused and allocate their time as promised when their are multiple competing managers/clients all screaming for blood (or perhaps just when their is one squeaky wheel).

We work intensively on internal projects whenever we have spare developer time. But we often pause them when client's need those developers. This really messes up the velocity statistics.

It would really help a lot if results could be split out and presented down to the level of a team member. Ultimately, it would be great to see velocity per developer, and total (weighted) points per developer.

If rather than just knowing who accepts a story, you knew the composition of the pair working on a story, then you could use actual costs for each developer to measure financial performance. This could be very helpful in a diverse team where some people are consultants, others are employees, and others are offshore developers.

Financial measurement, or even just points, allocated to individuals could be useful even when everyone is working for free on a few venture. This could be used to automatically allocate "equity" based on contributions. Using points assumes everyone's time is of equal value, using nominal dollar amounts (one person works for $1/hr, another works for $1.25/hr) could allow weighting to reflect other factors.

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.

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 think we should go a step further and make an option for lots of printer friendly output: current, history, done, icebox, charts. And print in formats for different uses. Have one layout with lots of graphs for "managment" and summary purposes. Have another layout with lots of details for accounting and project documentation/audit purposes. Have other layouts for team planning and status purposes.

It is never wise to even begin to use a product unless you can see how you can get out in case you grow out of it, or it fails to meet your needs over time. If a company doesn't build an exit strategy into its product it shows a lack of confidence that they can meet ongoing user needs or stay competitive with rivals.

So fool you if you're already a customer: 37signals won't introduce full export until they are confident their product is clearly superior. The fact that they add other bells and whistles while ignoring this feature suggests they do believe their product offers an inferior value proposition compared to alternatives.