Loading Profile...
Projects have Stories, Teams have Iterations/Velocity
I've used tracker for about 10 minutes so far and am already convinced it's the XP tracking tool I've been waiting for for nearly 10 years.
There's just one thing missing (from my perspective :)
Almost every XP team I've worked on has worked on more than one project simultaneously. From thsi I've come to the following pith observation: Projects have Stories and Releases, Teams have Iterations and Velocity.
What I mean by this is that Project A can have a bunch of estimated stories, and Project B can have a bunch of estimated stories. Team XYZ should have a fixed n-week iteration and of course, a velocity. They can stuff that iteration with stories from *either* project until they hit the velocity.
There's just one thing missing (from my perspective :)
Almost every XP team I've worked on has worked on more than one project simultaneously. From thsi I've come to the following pith observation: Projects have Stories and Releases, Teams have Iterations and Velocity.
What I mean by this is that Project A can have a bunch of estimated stories, and Project B can have a bunch of estimated stories. Team XYZ should have a fixed n-week iteration and of course, a velocity. They can stuff that iteration with stories from *either* project until they hit the velocity.
I’m glad it's finally here !
10
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 this under consideration.
-
Inappropriate?Oh yes! Alan has convinced me (in previous conversations) and it's made sense where I was oft confused before. Please consider this! Glad Tracker is here.
I’m glad and hopeful!
-
Inappropriate?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).
I’m inspired
-
Inappropriate?Well... I think I'm pretty nervous about the concept of individual velocity. It's not really fair to compare. I also don't think it matters that people drop in or out of teams. It's the Team that has the velocity (at least thats the way I do it).
Perhaps the Team is "37 Signals" or the team is the JPMorgan Database Projects Team, or the Team is just me. In all these cases, members may be added or removed and yesterdays weather still remains. All the projects that Team are working on still need to iteration-planned based on last iteration whether new folkd have joined, old folks have left, whatever.
What I think I'm saying is that Team is a first-class object, not just an attribute of individuals.
I agree that it's possibly less 'efficient', I'd also suggest it's the way most places operate.
Being able to have the Team schedule multiple projects allows for 'pseudo-projects'. Say my new app has a Rails backend and an iPhone frontend, I might choose to plan that as two 'projects' with the same Team. I can pick some high-priority iPhone stories and some high-priority Rails stories and the teams velocity shouldn't change if I tilt the balance one way or the other.
Is this helping ? I'm rambling. You'd think after teaching this stuff for ten years I'd be able to articulate it better. -
Inappropriate?Discovered this going through older topics. We're been considering the the concept of a "team", with it's own velocity, for a while now. I'm hoping to be able to tackle that at some point soon, but it would be a fairly big change, so we have to tread carefully. In the meantime, what we usually suggest is to try and organize projects in Tracker so that they align with stable teams as much as possible, and use labels within projects to identify stories related to a particular theme/customer/deliverable.
EMPLOYEE
