TL;DR
In your rather long question, this mixture of issues stood out as the gist of what you're really asking about:
Sometimes a design will be approved the first time, but other times it'll take 5 iterations. The only thought I had was to maybe re-score every time I have to do an iteration & bump it to the top of my sprint since that's still technically my priority? Either way, it makes forecasting design to be really hard and if I can't have semi-accurate story points for design, it becomes impossible to say how many points can be allocated doing front-end development stories for the development team project if a design story ends up taking forever due to multiple iterations.
When I parse this, a couple of things jump out at me:
- You are consistently taking on stories that can't be completed within a single iteration.
- You are carrying unfinished work across iterations, rather than placing unfinished stories into your backlog for re-prioritization by your Product Owner.
- You are viewing velocity as a management target rather than a trailing average or a range with a confidence interval.
The problem is only tangentially that you are matrixed across multiple teams; the real issue is that there is no rigor in your organization's iterative process or inspect-and-adapt cycle.
Stories Shouldn't Cross Iteration Boundaries
A story should be completable within a single iteration. Any story that can't be completed within an iteration is generally either:
- Incomplete due to improper estimation or unforseen roadblocks.
- An improperly-decomposed epic that lacks sufficient granularity.
These stories should be marked incomplete, assigned no points towards velocity or burn-down, and placed back onto the Product Backlog for discussion during the Sprint Retrospective, re-prioritization by the Product Owner, and further decomposition or analysis during some future Sprint Planning meeting when the story is back on the docket.
Unfinished Work is Never Automatically Carried Forward
Any story that isn't complete is "not done." It goes back into the Product Backlog, where the Product Owner may or may not find it relevant to the Sprint Goal of your next sprint.
Even if it remains a top priority, the work should probably not be carried forward as-is. If it was not completed within the sprint, it should be carefully reviewed to determine:
- If it was incomplete due to time or budget constraints.
- If there was some process issue at play that prevented its completion.
- If it was mis-estimated, and how it should be estimated in future.
- If it was improperly decomposed, and how it might be broken up into more actionable stories.
There are certainly other things one can review about incomplete work as part of the inspect-and-adapt cycle, but the short list above has generally addressed the vast majority of real-world cases I've run across. Feel free to adapt or invent your own style of introspection; just make sure you and your organization take the time to analyze the root cause of incomplete work, and the cost to the project of leaving any discovered issues unaddressed.
Velocity Isn't a Management Target
Velocity should reflect a team's capacity. If you are working on multiple teams, this will certainly affect the capacity of all three teams, and should be reflected as a visible cost to the projects you're involved with. This cost is most often made visible through a reduction in real velocity over time, a change in the slope of the project's burn-down, or through the number of incomplete stories left over at the end of each iteration. Such visibility is a Very Good Thing™.
It is generally best to calculate velocity as a trailing average over a number of sprints. I personally like to use the statistical mean of the past three months' worth of iterations, but you can use any sliding time box that makes sense for you. If your velocity wanders across more than two standard deviations from the mean, you probably need to revisit your planning and estimation process, along with uncovering any hidden roadblocks that might exist.
The utility value of tracking velocity is that it gives you a measure of confidence in future estimates. If you know that your velocity varies from 5-20 points per iteration, then expecting 20 points of stories to be completed every iteration is simply not a realistic expectation of your current process, but you could probably feel confident about delivering 5 points every single sprint.
When you or your organization start to use velocity as a goal, rather than a detective control to determine if your process is out of whack or a planning tool to determine how many iterations the current backlog will take to complete, then you are using the wrong tool for the wrong job. Velocity is simply statistical data; it is not a tool for developing fixed-scope schedules or delivery dates.
Use your real velocity to determine how many iterations you are likely to need to complete a given set of stories. Your Product Owner can then adjust the project's scope to change the number of estimated iterations required to meet management goals, but he can't manufacture velocity (incorrectly pronounced "productivity") by gaming the numbers.
Keeping Costs Visible
No invisible work, ever!
— CodeGnome's Law of Transparency
When you say that it sometimes takes five iterations for some design element to be approved, that isn't inherently bad. Iterative development often means things get refined or redone multiple times. However, if designs aren't being completed during a single iteration, it often means there's a process problem such as a lack of cross-functional team skills or a poorly-designed feedback loop in the design process.
Whether the multiple iterations to refine a design are good or bad is a judgment call for the organization. In either case, they represent a cost to the project, and this cost should always be visible. If it's simply the cost of doing business in your organization to do multiple redesigns, then this should be looked at as an acceptable cost, and there's no reason to sweep it under the rug. If it's considered sub-optimal, then the organization needs to keep that cost visible as a constant reminder that the relevant processes should be inspected and adapted until the cost becomes acceptable.
Visible costs are the grease that keeps the agile wheels turning smoothly. Costs that are higher than expected are a call to action, and their existence means that your process is properly detecting those higher-than-expected costs. This is not a process failure, but a process opportunity. Treat it as such.
