I guess your experience is very different than mine.
While I agree with your point about teams using one tool, the existing tools don't really capture this type of information and that's a problem. I've helped teams customize tools to include some of this type of stuff, but that can be a pain. It's often easier to just export to Excel or copy and paste. I've talked to a couple of tool vendors about making this easier, but none do so far.
In keeping with agile best practices I try to avoid being constrained by tools that don't do what is useful. I choose tools based on what I want to do, not the other way around. You say there is "zero interest in data not in the tool", I guess where you work nobody cares about UX metrics. I prefer to work at places where that's not the case. In fact, I've found printing a big copy of the UXI Matrix and hanging it up generates a lot of interest, and it drives teams to be aware of UX. Just like posting a burndown chart or using a physical Scrum board helps teams new to agile "get it."
I've also found it to be the case that a lot of teams still use Excel, just as Austin mentioned in his reply. In fact, I'd say it's the most common tool I've encountered, largely because a lot of product owners find it easier to create the initial list of stories in Excel. I first came up with the idea of listing the personas/users in columns because it drove me nuts to repeatedly enter the name of the user for many stories. Using this format saves me time when creating or updating backlogs in sprint planning meetings, which is really where it counts.
I agree that flow is important. When I first rolled out Scrum in a big organization, the UI designers couldn't keep up at first. We didn't do sprint 0s, and the developers were all complaining. I used an early version of the UXI Matrix to prioritize work, make it clear where the flow was broken, and to make sure the team was all on the same page about the big picture. In this case it was "sorry, you won't get a detailed spec for all stories, maybe we can pair up or just do something lightweight." We also had a lot of designers complaining that what we built sucked, because we did lightweight (or no) designs, and the developers were only focused on what their tool tracked, velocity of coding tasks.
The idea of the UXI matrix is to help folks map the design and research work into smaller more agile portions, and then provide the same level of visibility for UX work as development work. It also makes it easy to see false velocity. Hmm, lots of iterations, but user satisfaction is the same, or usability is actually getting worse...
Part of getting teams to understand the value of UX is making this stuff more visible. Google Analytics did wonders in terms of educating many folks about the power of data, yet it's a separate tool too. The lean startup crowd gets this stuff, they know that every iteration should be an experiment that allows you to learn how to make better products. Flow of code is not true progress, adding value to customers is, and if you aren't measuring UX in some way, you don't really know if you are just keeping busy or truly adding value.
That's my view...
On Feb 6, 2012, at 12:10 PM, kerrykimbrough wrote:
Jon, my 1st reaction to your UXI matrix concept is that no Scrum team I've ever seen would use it. No one wants to fuss with this much analysis and data entry. And, if the team is using Rally or similar tracking tools, there is zero interest in data that's not in the tool.
My 2nd reaction is that this matrix misses the point. What we need is good flow. We need work to arrive at each point in the flow completely ready for the next step. Devs don't want to fuss with your measures of UI design readiness. They want it to be ready.
We already know the waterfall flow, with its big hopeless handoffs, doesn't work. Instead, we seek a more continous and incremental flow. But I don't see how the UXI matrix contributes.