ProjectVelocity

Wiki.ProjectVelocity

SimpleVelocityExamplesForNewbies - NeilThorne

We've noticed some interesting correlations on our project velocity graphs. We track "big units" for stories (at 1, 2, or 3 per story), and "small units" for tasks (again 1 , 2 or 3). Having the two on the same chart is very revealing.

The two curves have the same sign slope everywhere, and almost always the same actual slope. We take this as confirmation that when we estimate stories we are estimating the same thing as when we're estimating tasks. The correllation is so strong as to be uncanny, in fact.

Also, we know that we have to do at least 15 small units worth of tasks in a two week iteration to get even one story completed that iteration, even though most of our stories don't have 15 small units worth of tasks associated with them. We have fallen foul of this on occasion when we've had several people out of the office (some on holiday, some sick, some on the road to see clients). Our rule of thumb is that "one pair makes no progress". The numbers re-inforce our impression that progress made by the team is super-linear with the number of pairs available, and that multi-story working is no good.

On the rare occaisions when we don't complete any stories (for whatever reason) it is nice to have the measure of tasks complete, if only to reassure ourselves that we were actually in the office doing stuff.

Has anyone else noticed any interesting properties of their project velocity? -- KeithB

Do you think you have the right granularity for your stories? Should they be smaller? Some projects only have one level of largish tasks for measuring progress. --SteveF

Having two kinds of thing to track works very well, we find

Initially, our stories tended to be too large, and our tasks too small, but after a few iterations worth of practice we seem to be getting it about right. In one sense, the granularity of our stories is right by definition, since it is largely chosen by our customer (with the occasional agglutination or split requested by us). The customer, sometimes a ProxyCustomer, sometimes not, has been learning too, of course, how to write better stories.

In the case of our current project, we spend a lot of our time re-writing GUI components. So a story is often something like "I want FooBars to look consistent with Frammitzes, exept that the first three Wombats should go on the Swoggle". That's a good granularity for the customer to track progress towards their goal of a consistent UI, but not good for us to track how much progress we're making towards fullfilling the stories for this iteration. Consider that, to make a change to a GUI component like this we might need to change a Java component and it's C++ peer for the general case, then again for the special case of the first three Wombats, and maybe tweak some of the framework classes too.

So, we can see that in this case, the question is not so much one of granularity, with a big story breaking down into smaller tasks, but instead a change of domain. A story, of the size that stories are in terms that the customer uses, needs a number of tasks to be carried out, of the size that tasks are in terms that the developers use. And there is an intimate connection between them, but it isn't whole-part.

I feel very strongly that devising the tasks that fulfill a story is not a process of analysis, of breaking down a large thing into component small things with more detail on them. That sort of thinking is what tripped up the structured analysis camp, and also crippled OO practice via the Rumbaugh/Booch "seamlessness" myth. Finding the tasks is a synthetic activity, combining together proposed changes to the codebase into manageable (in the sense, "can be used to manage the project") chunks.

It would be interesting to get some more information about the projects that have only "largish tasks". It seems to me that for this to be working, it's likely that the domain is one that doesn't have so strong a semantic boundary in it as does ours. Many of the things we do to change the behaviour of a GUI component aren't even in the customers' world-view. --KeithB

³³agent³Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)³ProjectVelocity