We call it a “product backlog” because there should be one per product. It’s not a project backlog or a team backlog. To have team backlogs would create prioritization problems (team A’s backlog could be entirely lower priority than team B’s but we wouldn’t know it if they were separate). I advise a single product backlog with multiple views into it (essentially MVC for backlogs). Some tools support such an approach.

The real answer for your situation though is that when someone on Team A works for Team X (the waterfall team doing testing) that work should not count in Team A’s velocity. Team A gets credit presumably for the points on the stories they “finish”. But those items aren’t really finished until they pass test (by Team x). So giving Team A credit for the story in sprint 3 when they “finish it” and then some more credit in sprint 4 when it’s tested is wrong. It overstates velocity.

It’s easy to see why: Suppose Team A does really sloppy work but claims to be done. They get say 5 points. Next sprint team x finds a ton of bugs and team A fixes them, claiming 3 more points of credit. Contrast that with Team A doing an awesome job and having no bugs found by Team x. In that case Team A would take no points in that second sprint. The sloppier Team A is, the more velocity points they get. Bad idea!

We have Team A, B, & C (scrum teams), their primary purpose is to work on new features; we also have team x (waterfall team) that is working on the final regression of the software product before it goes to production. However, team x needs more resources to finish by the deadline as well as need the knowledge and expertise of some of the folks on Team A, B & C. Team A, B,& C will lend team X a few folks, however, this now changes the resource count and velocity.
(Here’s the dilemna)

Some of the PMs feel that Teams A, B & C should still count the work that the loaned out members do for team X on their back log, so this way the resource count and velocity can be tracked and they feel that it would be accurate.

So the stories for Team A’s sprint backlog look like this for example:
Tasks Mon Tues Wed Thurs Fri
Code interface (team A task) 4
Test interface (team A task) 8
Add error logging (team A task) 4
Test languages (team X task) 4
Stabilize the Eval Environment (team x task) 4
Write the xyz class (team A task) 8

I on the other hand proposed your method on how to track velocity with a varying amount of team members from sprint to sprint, but I can’t get them to see that the impediments on team x are much different than the ones that team A experiences and can toy with their velocity numbers and make them inaccurate. Also, team X doesn’t track velocity, so management feels that we should track team velocity whenever we can, even if it means adding another project’s story to their backlog, just so the number of resources can stay the same.

The feedback that I am getting from managers is that there is a lot of overhead and no benefit to combining the 2 projects into 1 backlog because the loaned resource (from Team A for example) still has to:
• provide status to their team as well as Team X
• still go to team A’s planning meetings
• estimate stories for team A as well as provide estimates on the stories that they will do for team
• Enter their time into Team A’s scrum tool for the hours that they did worked on the tasks for team X

The way we use to do it, was treat the loaned resource as “time away from their project” so they can go work on the other project 100%. This would also allow us to use your method to track velocity for a varying team.
So I was hoping to get more feedback from you as to why 2 projects should not be combined into 1 backlog. Amazing there isn’t much information about this on the internet, I have tried to searching and I believe you are the only one who has at least offered up a solution to track varying resources. Feel free to let me know when there is a good time to track stories from 2 different projects in backlog as well, because I can’t personally think of any reason.
I apologize for the length of this, but would appreciate any advice that you have to offer.
Thanks,
Krystal

About team velocity, it measures how much of the backlog (story points) the team can consume (produce working software) in a iteration, right ? I have a question about how to compare velocities across different teams in different projects. Since story points are relative, velocity is as well. Ex: Team A in project I can consume 10 points per iteration and team B can consume 10 points in project II. Looking at the velocity it seems that both are equally productive, but in a further investigation you realize that team A used a very small story as base ( attributed 2 story point to it), and team B used a larger one. Considering this scenario, how can I compare velocities among projects? Even more, what kind of metrics I can collect and compare across projects?

Thanks a lot,
Diogo

I normally make the assumption that sick time will be constant from sprint to sprint. For vacations, if I’m looking ahead 3-6 months I will normally just assume that I don’t know when vacation will occur but that it is already accounted for in how I use a range of velocities to make predictions.

For holidays, if it’s a simple one-day thing I usually don’t worry about. If it’s something like Christmas or the US Thanksgiving holiday that are multiple days and seem to have a bigger effect because people are less focused, I do try to account for them. It’s October 25 as I’m writing this. If I were putting together a 3-month plan right now I would probably assume a slight drop in velocity around late November and late December/January 1 to account for this.

I’d either wing it and guess at how much to drop velocity by OR (even better) I’d look at what happened last year. I constantly tell companies to capture this type of data. Wouldn’t it be nice right now to know very simply that velocity dropped by an average of 25% for the sprints of comparable length that included Christmas last year? I wouldn’t make adjustments for team size or how many days of planned vacation were in those sprints, etc. I’d just want to know what the average drop was in percentage terms by sprint length.

If I were predicting velocity for a team that has never worked together and had only 1-2 sprints of history I would express my estimate of velocity as a range. I would use whatever historical data I have (from the 1-2 sprints) and would look at standard deviations of velocity from all other teams and apply that plus a good dose of my own common sense and intuition. But, even better, I would try not to be in a position where someone needs an absolutely perfect date from me for a team that has no prior history. I’d be willing to come up with an answer but I’d want them to understand all the potential problems with it.

I have found the best use of the story point averages are within the Sprint Planning meeting where they are used as a reality check to avoid over zealous teams signing up to too much work. The difference I have seen in taking this approach rather than just to base the next sprint on the previous sprint, is that teams are completing their work within the sprint period more and more.